Windows reconnaît-il les liens symboliques de Linux?

Je me demandais simplement comment un système Windows gère les liens symboliques. Ma meilleure supposition est qu'il ne les reconnaîtra pas, mais je ne suis pas tout à fait sûr.

Aussi, que font les Mac face à un?

Dépend de la version Windows et de la configuration côté serveur lorsque nous parlons de disques non locaux.

Depuis Windows Vista, Windows a une idée des liens symboliques, mais la sémantique diffère. Mais le problème le plus important ici devrait être les noms de chemin, qui suivent une syntaxe différente. Pour commencer: arborescence de répertoires à racine unique du côté unixoïde et plusieurs lettres de lecteur en tant que racines du côté Windows.

Du côté unixoïde, les liens symboliques sont simplement des fichiers texte avec un drapeau spécial. Côté Windows, le mécanisme sous-jacent est appelé un point d'analyse. Cela indique au gestionnaire d'objets de le passer à des filtres enregistrés particuliers ( la métadate pour cela est stockée dans les points d'analyse). Windows 2000 a déjà introduit un type de points d'analyse appelés points de jonction (à peu près, mais pas tout à fait, des liens symboliques de répertoire). Avec Vista, ils ont introduit des liens symboliques vers des fichiers et des répertoires, également sur des lecteurs distants. Et les liens symboliques sur les lecteurs distants sont également pris en charge dans une certaine mesure.

Le point principal est de savoir si le pilote du système de fichiers - lorsqu'il est exécuté localement - ferait des ajustements aux chemins que Windows voit. Dans un tel cas, cela fonctionnerait pour certains liens symboliques locaux / relatifs. Pour les chemins absolus comme cibles, les choses deviendront difficiles et impossibles à déduire ce que l'on veut dire. Idem pour les liens de liens symboliques distants (vers des "partages réseau").

En ce qui concerne le côté Mac, je n'en ai aucune idée et cela pourrait avoir un sens en tant que question distincte. Mais tant que le côté serveur transmet l'information qu'il s'agit d'un lien symbolique, je ne vois aucun problème, car ils suivent tous les deux la sémantique SUS (contrairement à Windows).

Tenez compte des points de montage latéraux Linux:

/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var

Et maintenant, considérons un lien symbolique /home/paul/fstabpointant vers /etc/fstab. Ils sont situés sur deux volumes différents que Windows - s'il est capable de les voir via un pilote de système de fichiers (qui fonctionne!) - ne peut pas dire qu'ils appartiennent ensemble comme /etc/fstabdécrit. Ainsi, le lien, que Windows verrait sous un dossier \paul\fstab, même s'il était traduit, pointerait vers \etc\fstab, qui n'existe pas /dev/sda2. Et si ce lien symbolique pointait vers le chemin relatif, les ../../etc/fstabchoses ne changeraient pas du tout.

L'essentiel: Donc, même si cela peut être envisagé pour que cela fonctionne pour certains cas d'angle, le fait que la sémantique et la syntaxe diffèrent des deux côtés de la clôture, il est peu probable que vous trouviez une méthode pratique et générique qui fonctionne.

La réponse de 0xC0000022L est approfondie pour le côté Windows des choses. Le Mac peut reconnaître les liens symboliques de Linux; cependant, Linux ne peut pas reconnaître les alias créés dans le Finder du Mac (les liens symboliques créés à l'aide de ln -s fonctionnent correctement).