I see this issue also on Windows slaves.

Example:
Jenkins reports workspace 260GB ( http://<host>:8080/plugin/disk-usage/ )
Windows properties on the workspace folder reports 49GB
Cygwin 'du -hs' reports 49GB

You are certainly right.
And the method hudson.Util.isSymLink(File) seems perfect to use on every file going through the disk-usage plugin.

But, what would be the performance on a very large number of files?
When using Java 6 vs Java 7 ?
And when using Windows vs Linux?
I do not know the answers to these questions, but you can try with a fork of the disk-usage plugin.

I think performance is important, but less important than correctness.

Also isn't the disk usage calculation anyway running as a background thread?

You may also consider that following a symlink to a directory potentially causes more files/dirs to be examined, so in those cases it will probably be faster overall, due to fewer total number of files/dirs.

> performance is important, but less important than correctness
Yes, of course correctness is important, but less important than the plugin causing unavailability of Jenkins for some of the people, including you.

I do not say that this should not be changed; I say that the change should certainly be tested with a large number of files, in several environments, before being pushed.

What about only checking for symlinks for directories?

My suggestion is to make this part of the next plugin release, but controlled by a global option (and keep the default behaviour unchanged - follow all symlinks).

The global option could also control different behaviour for file/directory symlink, as 'centic' suggested.

I would be happy to help with testing.

When I wrote this ticket, the original environment was linux clearcase dynamic views.

For those that haven't had suffered with clearcase in a unix environment, it
creates a virtual file system /vobs (vobs/subdirs based on how you divide your typically monolithic repository)
creates a sorta workspace /view/workspace_name
inside the sorta workspace has /view/workspace_name/vobs/whatever
also in the sorta workspace is /view/workspace_name/links_to_all_root_filesystem_elements

so, if you follow smylinks you have infinite recursion.

@Ben Golding
I am not against a configuration option.
Of course, it seems better if it "just works" without configuration (in all environments), but otherwise configuration is supposed to be better than a "bug".

Most important is that you may need to submit a github pull request with working code in order to make it accepted by the plugin maintainer.

Why we should calculate symlinks at all?
Adding hudson.Util.isSymLink(File) wouldn't cause performance degradation because of page objects cashes in kernel.