Me preguntaba cómo un sistema Windows maneja enlaces simbólicos. Mi mejor conjetura es que no los reconocerá, pero no estoy completamente seguro.
Además, ¿qué hacen los Mac cuando se enfrentan con uno?
Me preguntaba cómo un sistema Windows maneja enlaces simbólicos. Mi mejor conjetura es que no los reconocerá, pero no estoy completamente seguro.
Además, ¿qué hacen los Mac cuando se enfrentan con uno?
Respuestas:
Depende de la versión de Windows y la configuración del lado del servidor cuando hablamos de discos no locales.
Desde Windows Vista, Windows tiene una idea de los enlaces simbólicos, pero la semántica difiere. Pero el problema más importante aquí debería ser los nombres de ruta, que siguen una sintaxis diferente. Para empezar: árbol de directorios de raíz única en el lado unixoide y varias letras de unidad como raíces en el lado de Windows.
En el lado unixoide, los enlaces simbólicos son simplemente archivos de texto con una bandera especial. En el lado de Windows, el mecanismo subyacente se denomina punto de análisis. Esto le dice al administrador de objetos que lo pase a filtros registrados particulares (la meta-fecha para esto se almacena en los puntos de análisis). Windows 2000 ya introdujo un tipo de puntos de análisis conocidos como puntos de unión (aproximadamente, pero no del todo, enlaces simbólicos de directorio). Con Vista, introdujeron enlaces simbólicos a archivos y directorios, también en unidades remotas. Y los enlaces simbólicos en unidades remotas también son compatibles en cierta medida.
El punto principal es si el controlador del sistema de archivos, cuando se ejecuta localmente, haría algún ajuste en las rutas que Windows puede ver. En tal caso, funcionaría para ciertos enlaces simbólicos locales / relativos. Para caminos absolutos como objetivos, las cosas se volverán difíciles e imposibles de deducir lo que significa. Lo mismo para enlaces remotos de enlaces simbólicos (a "recursos compartidos de red").
En cuanto al lado de Mac, no tengo idea y podría tener sentido como una pregunta separada. Pero mientras el lado del servidor transmita la información de que se trata de un enlace simbólico, no veo problemas, ya que ambos siguen la semántica del SUS (a diferencia de Windows).
Considere los puntos de montaje lateral de Linux:
/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var
Y ahora considere un enlace simbólico que /home/paul/fstab
apunta a /etc/fstab
. Están ubicados en dos volúmenes diferentes que Windows, si puede verlos a través de un controlador de sistema de archivos (¡lo que funciona!), No puede distinguirlos como se /etc/fstab
describe. Entonces, el enlace, que Windows vería debajo de una carpeta \paul\fstab
, incluso si estuviera traducido, apuntaría \etc\fstab
, que no existe /dev/sda2
. Y si ese enlace simbólico apuntara a la ruta relativa, las ../../etc/fstab
cosas no cambiarían en absoluto.
Lo esencial: por lo tanto, si bien es concebible que pueda hacer que funcione para algunos casos de esquina, el hecho de que la semántica y la sintaxis difieran en ambos lados de la cerca hace que sea poco probable que encuentre un método práctico y genérico que funcione.
ntfs
admite puntos de montaje (por si no te gustan todas esas letras).
La respuesta de 0xC0000022L es exhaustiva para el lado de Windows. La Mac puede reconocer los enlaces simbólicos de Linux; sin embargo, Linux no puede reconocer los alias creados en el Finder de Mac (los enlaces simbólicos creados con ln -s funcionan bien).
.lnk
archivos).