en Java, un lien symbolique dans un environnement UNIX peut être détecté en comparant le chemin canonique et absolu du fichier. Cependant, cette astuce ne fonctionne pas sur Windows. Si j'exécute
C:\bar C:\bar
3 Réponses :
La réponse est "non". Les points de jonction et les liens symboliques ne sont pas le même genre de chose. Le JRE ne les recherche pas, et les fonctions que vous citez ne les différencient pas. P>
Cela dit, vous pourriez accomplir quelque chose avec ce qui suit: p>
Si le répertoire jonctionné contient du contenu, le résultat d'obtenir le chemin canonique de quelque chose ci-dessous peut être «surprenant» et révéler la situation, puisqu'il s'agira probablement d'un chemin de chemin sous la cible de la jonction. Cela ne fonctionne que si le répertoire pointé par la jonction est, bien sûr, non vide. P>
Un point de jonction dans Windows est une entité système de fichiers qui vous redirige vers un autre emplacement (éventuellement sur un autre volume) et transparent à tous les fichiers d'ouverture et de lecture du système de fichiers. Comment ne ressemble-t-il pas exactement à un lien symbolique (POSIX)? Autre que celui sur Windows, c'est appelé une jonction si elle est utilisée pour un répertoire et un symbole symbolique si c'est pour un fichier?
Le point de ma question est que Dislink the JVM sur Linux, le JVM sous Windows ne retournera pas différentes valeurs canoniques et absolues pour la jonction (ou un lien symbolique de répertoire ou l'un des contenus qui y figurent).
Dans un système de fichiers Linux, il y a un backpointer dans l'inode au vrai parent, et non à aucun lien symbolique. Similiaire dans les NTFS. Quel point de jonction est comme un point de montage i>.
Vous pouvez essayer ce hack sale pour Windows
if (f.isDirectory() || f.isFile()) { System.out.println("File or Directory"); } else { System.out.println("Link"); }
Cela ne fait rien d'utile. ISDirectory () retournera true pour un répertoire normal, un lien symbolique de répertoire (fabriqué avec mklink / j) ou une jonction (fabriqué avec mklink / j). Tout autre type de lien ou de raccourci sera vrai pour ISFile (). Votre confusion peut découler du fait que si vous créez un raccourci vers un répertoire ou un fichier, il apparaît comme «foo», mais sur le disque, c'est représenté comme «foo.lnk», donc isdirectory () et isfile () retournera false pour ' Foo '(mais alors aussi ()))). Les raccourcis sont en tout cas, un artefact de l'Explorateur Windows uniquement et n'a rien à voir avec ce que je demandais.
Il ne semble pas y avoir de mécanisme de plate-forme transversale pour cela dans Java 6 ou plus tôt, bien que sa tâche assez simple à l'aide de JNA modifier: mise à jour par commentaire sur la possible retour d'erreur par getwin32fileattributes () code> p> p>
Juste un fyi, getfileattributesw () code> renvoie
0xFFFFFFFF code> (
-1 code> comme
int code>) s'il échoue.
isjunkortorMink () Code> doit vérifier cette condition avant de pouvoir vérifier le drapeau
0x400 code>, sinon il retournera un faux positif. Étant donné que
getfileattributesw () code> échouera si le fichier n'existe pas, la vérification du
f.exists () code> est redondant.
Vous pouvez utiliser une méthode JNI pour obtenir des attributs de fichier et vérifier si c'est un point de reparsse
Devrait ajouter d'autres que Java 7 ne détecte pas les jonctions comme des liens symboliques non plus.