Sorry, i don't understand. What you you mean with "TFS" ?
Its an issue in v 1.361 and maybe together jobConfigHistory plugin.

If you look closely this issue was originally reported against the TFS component, ie TFS plugin.

I can confirm that this issue occurs on 1.161 in combination with the "Hudson Job Configuration History Plugin" version 1.5.
Disabling the Job Config History plugin seems to solve the problem. So I would guess that that plugin is holding a file reference which is inhibiting the delete on windows systems.

For the record I've tested this on a Windows 2000 SP4 server running on jdk 1.6.0_20 with the winstone runner.

Assigning to job configuration history plugin. Maybe the maintainer of that plugin knows what can be done

After a look into our code, the only code location where we access the original config.xml file (in read-only mode) is in http://fisheye.jenkins-ci.org/browse/Hudson/tags/jobConfigHistory-1.5/src/main/java/hudson/plugins/jobConfigHistory/ConfigHistoryListenerHelper.java?r=31559#l167. The file is opened, copied and closed immediately:

 
   private void copyConfigFile(final File currentConfig, final File timestampedDir) throws FileNotFoundException, IOException {

        final FileOutputStream configCopy = new FileOutputStream(new File(timestampedDir, currentConfig.getName()));
        try {
            final FileInputStream configOriginal = new FileInputStream(currentConfig);
            try {
                Util.copyStream(configOriginal, configCopy);
            } finally {
                configOriginal.close();
            }
        } finally {
            configCopy.close();
        }
    }

Elsewhere we operate on the historized files only.
So I do not think the jobConfig history plugin is responsible. As the plugin was released first Feb 01 2010
comments from 2009 are definitely not related . I will change the component to unknown, then.

I would even suggest to decrease the priority as well, a really critical would not stay in the wild for more than a year hopefully .

Best Regards
Mirko

Putting it to back to TFS, though I would suggest closing this bug as "Can not reproduce", there are lots of stacktraces in this issue which IMHO only have Windows-OSes in common, but are otherwise unrelated .

Ok, can not reproduce the TFS problem. Please open up a new issue for jobconfig (or misc).

Hello,

i also reproduced problem with file access through job histoty plugin (s.a.). After i deactivted the plugin the problem immediately disappeared. I am sure that it has something todo with the job history plugin, why else this effect?
Maybe it has something todo with "hudson on windows server" installations plus the job histoty plugin because of file access rights managment, but i gave all rights for the service acccount of tomcat/hudson was running on and the problem stayed.

Please submit a new bug for the jobConfigHistory-Plugin then instead of discussing this in this unrelated bug. As I wrote above I am somewhat at loss regarding this issue, we do not run hudson on a Windows-Server and on my workstation I can not reproduce this problem.

i cant see that this is related to the TFS plugin, as you re-opened it referenced the job-history plugin. This issue is marked as belonging to the tfs plugin, and not the job-history plugin. Im just doing some cleaning for a upcoming tfs release.