Impossible d'accéder au fichier Java créé - parfois

Question

En Java, je travaille avec le code en cours d'exécution sous Windows XP qui crée un fichier comme ceci:

    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 
     } 
    } 

Parfois, lorsqu'un fichier est créé de cette façon, il est à peu près totalement inaccessible de l'extérieur du code (même si le code responsable de l'ouverture et de la lecture du fichier n'a pas de problème), même lorsque l'application n'est pas en cours d'exécution. Lorsque vous y accédez via l'Explorateur Windows, je ne peux pas déplacer, renommer, supprimer ou même ouvrir le fichier. Sous Cygwin, je reçois ce qui suit quand je ls -l le répertoire:

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

Comme le laisse entendre, les noms de fichiers sont grands, mais sous la pour XP (si elles sont un peu plus de 200 caractères) 260 caractères max.

Pour ajouter encore au sentiment que mon ordinateur veut juste que je me sente stupide, parfois les fichiers créés par ce code sont parfaitement normaux. Le seul motif que j'ai repéré est qu'une fois un fichier dans le répertoire "verrouille", le reste est vissé.

Quelqu'un at-il déjà rencontré quelque chose comme ça avant, ou avez-vous un aperçu de ce qui se passe ici?

Answer 1

Bien que, par définition, NTFS doit gérer la longueur du trajet jusqu'à 2^15-1, dans la pratique la longueur des chemins est limitée à 255.

Vous pouvez créer des fichiers avec un nom de chemin plus long (nom de fichier, y compris parent noms de dossier), mais vous ne pouvez pas y accéder par la suite. L'erreur que j'obtiens dans ces cas est que le fichier n'a pas pu être trouvé. Pour se débarrasser de ces fichiers, je dois raccourcir les noms des dossiers parents, jusqu'à ce que la longueur du chemin soit suffisamment courte.

Answer 2

Assurez-vous de toujours fermer le flux dans un bloc finally. Dans votre cas, si une exception est levée, le flux risque de ne pas se fermer et de laisser échapper un descripteur de fichier. Vous pouvez utiliser procexp de SysInternals pour voir quel processus contient le descripteur du fichier.