The existing code assumes that the workspace being used by the job that's running the cleanup process is unique to that build, and hence can safely be removed from all other slaves.  This assumption is incorrect.

If two jobs are defined with the same "custom workspace folder" then their independent cleanup processes will both be hitting the same folder on all slaves, so one can knock out the workspace of the other.

== Steps to reproduce ==

• define two jobs using the same, custom workspace (/var/hudson/custom). At least, that's what I did. One job should also be sufficient.
• launch a (UNIX) slave, tie two previously mentioned jobs to it
• build both projects
• drink (potentially lots) of coffee and wait for the workspace cleaner to visit the slave

== Actual result ==

• the workspace (/var/hudson/custom) is wiped when the clean workspace job has run. If the first workspace doesn't use a custom workspace, the problem does not occur. It seems that the cleaner doesn't take the custom workspace configuration into account to determine which workspaces are stale.

== Expected result ==

• The custom workspace /var/hudson/custom remains intact after clean workspace job has run.