views:

45

answers:

2

In Java, I'm working with code running under WinXP that creates a file like this:


   public synchronized void store(Properties props, byte[] data) {
      try {
         File file = filenameBasedOnProperties(props);
         if ( file.exists() ) {
            return;
         }         
         File temp = File.createTempFile("tempfile", null);
         FileOutputStream out = new FileOutputStream(temp);
         out.write(data);
         out.flush();
         out.close();
         file.getParentFile().mkdirs();
         temp.renameTo(file);
      } 
      catch (IOException ex) {
         // Complain and whine and stuff
      }
   }

Sometimes, when a file is created this way, it's just about totally inaccessible from outside the code (though the code responsible for opening and reading the file has no problem), even when the application isn't running. When accessed via Windows Explorer, I can't move, rename, delete, or even open the file. Under Cygwin, I get the following when I ls -l the directory:

ls: cannot access [big-honkin-filename]
total 0
?????????? ? ? ? ?            ? [big-honkin-filename]

As implied, the filenames are big, but under the 260-character max for XP (though they are slightly over 200 characters).

To further add to the sense that my computer just wants me to feel stupid, sometimes the files created by this code are perfectly normal. The only pattern I've spotted is that once one file in the directory "locks", the rest are screwed.

Anybody ever run into something like this before, or have any insights into what's going on here?

+3  A: 

Make sure you always close the stream in a finally block. In your case if an exception is thrown the stream might not get closed and will leak a file handle. You could use procexp from SysInternals to see which process holds the handle to the file.

Darin Dimitrov
Sound advice and a worthwhile tweak, but it's not throwing an exception, so it seems unlikely that's my root cause.
BlairHippo
Process Explorer doesn't show anybody has having the handle to the file; I enter the filename in Find -> Find Handle or DLL... and get 0 matching items in the search.
BlairHippo
+1  A: 

Although, by definition, NTFS should handle path length up to 2^15-1, in practice the length of paths is limited to 255.

You can create files with a longer path name (filename including parent folder names), but you cannot access them afterwards. The error I get in these cases is that the file could not be found. To get rid of these files, I have to shorten the names of parent folders, until the path length is short enough.

Christian Semrau
Holy crap, this is precisely what it is. Thanks!
BlairHippo