2010-03-25 7 views
6

Depuis Java, j'extrais un exécutable dans un emplacement spécifié à l'aide de File.createTempFile(). Lorsque j'essaie d'exécuter mon exécutable, mon programme se bloque lorsqu'il essaie de lire la première ligne de sortie.Comment désemméler les noms de fichiers Windows en Java?

J'ai découvert que si j'essaie d'exécuter le même exécutable extrait à partir d'un autre programme, cela fonctionne si je spécifie le répertoire C: \ Documents and Settings \ nom_utilisateur \ Local Settings \ Temp \ prog.exe. Mais si je spécifie le répertoire comme C: \ DOCUME ~ 1 \ USERNA ~ 1 \ LOCALS ~ 1 \ Temp \ prog.exe je reçois le coup.

Existe-t-il un moyen de démonter le nom de fichier tilde dans mon programme afin que je puisse spécifier un nom de répertoire qui fonctionnera?

(Et puisque je aime toujours aborder les problèmes de conception et de langue API, est-il une raison pour laquelle Java File.createTempFile() et java.io.tmpdir doivent évaluer les noms de fichiers déchiquetés?)

Répondre

10

Vous pouvez utiliser getCanonicalPath() pour obtenir le chemin élargi. .: par exemple

try 
{ 
    File file = File.createTempFile("abc", null); 
    System.out.println(file.getPath()); 
    System.out.println(file.getCanonicalPath()); 
} 
catch (IOException e) {} 

... produit ...

C:\DOCUME~1\USERNA~1\LOCALS~1\Temp\abc49634.tmp 
C:\Documents and Settings\username\Local Settings\Temp\abc49634.tmp 

J'ai testé cela sur XP, mais supposons qu'il fonctionnerait de la même sur d'autres systèmes d'exploitation Windows.

Voir la réponse de @ raviaw à votre deuxième question.

+0

Mieux vaut répondre que le mien, même si je doute que c'est son problème. –

+0

Cela semble en effet démystifier les noms de fichiers! D'une manière ou d'une autre, ça continue de se bloquer quand je cours. Je ne comprends pas encore pourquoi, mais je travaille dessus ... – skiphoppy

+0

Ah ah! J'ai dû appeler close() sur le OutputStream que j'ai utilisé quand j'ai extrait l'exécutable. Il s'avère que lors de mon test, je passais par inadvertance le nom de fichier altéré pour un exécutable encore utilisé (et non fermé()) par mon application, et en passant un nom de fichier complet pour une extraction précédente non utilisée. – skiphoppy

3

Wow, je n'ai jamais vu ça. Le fait est que la variable d'environnement% TEMP% retourne un nom mutilée (ce qui est de mon ordinateur):

 
TEMP=C:\DOCUME~1\raviw\LOCALS~1\Temp 
TMP=C:\DOCUME~1\raviw\LOCALS~1\Temp 

En supposant qu'un nouveau créer la machine virtuelle Java utilise la variable d'environnement pour obtenir l'emplacement du dossier temporaire, il est La faute de VM que les répertoires viennent à être brisés.

Et même si vous essayez d'utiliser System.getenv() pour obtenir le dossier temporaire, vous aurez toujours le même problème.

Je veillerais que:

  • Le problème ne provient pas du fait que vous avez un répertoire appelé « prog.exe » (en fonction de votre question, je suppose cela);
  • Si le fichier est "prog.exe", s'il n'était pas utilisé par un autre programme (un antivirus, par exemple);
  • Vérifier si votre ordinateur est sain d'esprit (ce serait un bogue critique pour toute application qui n'est pas une application web et qui a besoin de fichiers temporaires).
+0

+1 pour la réponse à sa deuxième question que j'ai oublié d'aborder. – Chris

+0

Il s'avère qu'il était utilisé par un autre programme ... l'application que j'écrivais.Ce qui l'avait extrait, et n'a jamais appelé close(). Donc, tous les appels pour essayer de l'exécuter, que ce soit à partir de mon test ou de l'application, étaient suspendus indéfiniment en attente de ce close() et le vidage sur le disque. – skiphoppy

Questions connexes