¿"Unión de directorio" vs "enlace simbólico de directorio"?


395

En el contexto de NTFS:

MKLINK [[/D] | [/H] | [/J]] Link Target

/D Crea un enlace simbólico de directorio. El valor predeterminado es un enlace simbólico de archivo.
/H Crea un enlace duro en lugar de un enlace simbólico.
/J Crea una unión de directorio.
Link especifica el nuevo nombre del enlace simbólico.
Target especifica la ruta (relativa o absoluta) a la que se refiere el nuevo enlace.

  1. ¿No es una unión de directorios exactamente lo mismo que un enlace simbólico de directorio ?

    ¿Cuál es la diferencia entre mklink /D f1 f2y mklink /J f1 f2?

  2. Dado que un "directorio" es en realidad solo un archivo , ¿cuál sería la diferencia entre un enlace simbólico de directorio y un enlace simbólico de archivo?


Respuestas:


366

Una unión definitivamente no es lo mismo que un enlace simbólico de directorio, aunque se comportan de manera similar. La principal diferencia es que, si está mirando un servidor remoto, las uniones se procesan en el servidor y los enlaces simbólicos del directorio se procesan en el cliente . Vea también el comentario de Matthew sobre el hecho de que esto significa que los enlaces simbólicos en el sistema de archivos local pueden apuntar a sistemas de archivos remotos.

Suponga que en una máquina llamada Alicia se colocaría un punto de unión c:\myjpy un enlace simbólico de directorio c:\mysymlink, ambos apuntando a c:\targetfolder. Mientras estés usando Alice, no notarás mucha diferencia entre ellos. Pero si está utilizando otra máquina llamada Bob, entonces el punto de unión

\\Alice\c$\myjp apuntará a \\Alice\c$\targetfolder

pero el enlace simbólico

\\Alice\c$\mysymlink apuntará a \\Bob\c$\targetfolder

(Advertencia: de forma predeterminada, el sistema no sigue enlaces simbólicos en volúmenes remotos, por lo que en la mayoría de los casos el segundo ejemplo en realidad dará como resultado "Archivo no encontrado" o "No se puede seguir el enlace simbólico porque su tipo está deshabilitado" ).

La diferencia entre un enlace simbólico de directorio y un enlace simbólico de archivo es simplemente que uno representa un directorio y el otro representa un archivo. Dado que el objetivo del enlace no necesita existir cuando se crea el enlace, el sistema de archivos necesita saber si decirle a las aplicaciones que es un directorio o no.

También debe tenerse en cuenta que la creación de un enlace simbólico requiere un privilegio especial (de forma predeterminada, solo está disponible para procesos elevados), mientras que la creación de una unión solo requiere acceso al sistema de archivos.


13
Para ser claros: bien puede haber otras diferencias funcionales más sutiles entre las uniones de directorio y los enlaces simbólicos de directorio. Lo remoto frente a lo local es lo más obvio desde la perspectiva de un usuario (a diferencia de un desarrollador).
Harry Johnston

12
@MatthewSteeples, ¿quiere decir que si creo un enlace simbólico C:\testlink(que apunta a C:\testmi computadora) y alguien accede remotamente a mi computadora y hace clic en C:\testlink, se resolvería C:\testen su computadora, mientras que si creo una unión de directorio C:\testlink(que apunta a C:\testen mi computadora), y alguien accede remotamente a mi computadora y hace clic en C:\testlink) ¿lo conduciría a C:\testmi computadora? ¿O lo entendí al revés?
Pacerier

99
@Pacerier en este contexto sí, pero los enlaces simbólicos le permiten tener una carpeta en su computadora que apunta a un recurso compartido de red (porque están resueltos del lado del cliente). Por ejemplo, C: \ MyNetworkShare en realidad podría apuntar a \\ Alice \ Share
Matthew Steeples

66
@MatthewSteeples, pero ¿no podríamos crear una unión de directorios C:\MyNetworkShareque apunte \\Alice\Sharetambién?
Pacerier

8
@Pacerier, no, los puntos de unión deben ser locales.
Harry Johnston

56

La conversación compleja duele el cerebro: me gustan los gráficos:

Suponga que any MyLinkes un enlace simbólico y any MyJunces una unión que apunta a Target as created.

p.ej

mklink /D MyLink C:\T_Dir para crear un enlace simbólico al directorio de destino

mklink /J MyJunc C:\T_Dir para crear una unión de directorio al directorio de destino

Donde la sintaxis es mklink [/J,/D] [link path] [target path]como se escribe en la máquina local


 link path    |   target path   |         When accessed ..
              |                 |  (locally)    |    (remotely)
              |                 |               |
C:\MyLink     |   C:\T_Dir      |  C:\T_Dir     |  [leads back to local]
C:\MyJunc     |   C:\T_Dir      |  C:\T_Dir     |  [leads to remote]
              |                 |
\\Svr\MyLink  |   C:\T_Dir      |   C:\T_Dir    |  [leads back to local]
\\Svr\MyJunc  |   C:\T_Dir      |  *** Must create and point local ***
              |                 |
C:\MyLink     |  \\Sv2\T_Dir    |  \\Sv2\T_Dir  |   Error*1
C:\MyJunc     |  \\Sv2\T_Dir    |  *** Error - Must point local ***
              |                 |
\\Svr\MyLink  |  \\Sv2\T_Dir    |  Error*1
\\Svr\MyJunc  |  \\Sv2\T_Dir    |  *** Must create link using target device ***

Error * 1: si desbloqueó el acceso a enlaces simbólicos remotos en su máquina local, esto funcionaría ... pero solo en la máquina local donde está desbloqueado


3
Eso es muy raro Incluso los enlaces simbólicos relativos no funcionan de forma remota. Por ejemplo, creo un directorio d:\_tmp\data. Crear un enlace de esta manera: d:\_tmp>mklink /d data-link data. El usuario remoto tiene acceso completo d:\_tmpy todas sus subcarpetas PERO aún no podrá abrirlo d:\_tmp\data-link.
Nux

44
Esto se debe a que cuando se evalúa un enlace simbólico del lado del cliente, estaría apuntando a d: \ _ tmp \ data en el cliente, no en el servidor.
Apraetor

Creo que la razón por la que es raro está clara. Pero estoy de acuerdo con @Nux en que ES EXTRAÑO, al menos en el caso de enlaces simbólicos relativos.
Jon Coombs

Complex talk hurts brain -- I like chartsMe encanta esta oración, y la tabla también.
Luke

46

Los enlaces simbólicos tienen más funcionalidad, mientras que las uniones casi parecen ser una característica heredada debido a sus limitaciones, pero las implicaciones de seguridad de estas limitaciones son específicamente por qué una unión podría preferirse a un enlace simbólico. La segmentación remota hace que los enlaces simbólicos sean más funcionales, pero también aumenta su perfil de seguridad, mientras que los cruces pueden considerarse más seguros porque están restringidos a rutas locales . Por lo tanto, si desea un enlace local y puede vivir con una ruta absoluta, probablemente sea mejor con un cruce; de lo contrario, considere un enlace simbólico para sus habilidades adicionales.

ingrese la descripción de la imagen aquí

** La declaración de diferencia en velocidad / complejidad proviene de una declaración no verificada en la entrada de Wikipedia sobre puntos de análisis NTFS (una buena lectura). *


Otras comparaciones de enlaces NTFS

Aquí hay algunas otras comparaciones sobre el tema, pero pueden ser engañosas al considerar los cruces porque no enumeran los beneficios que enumero anteriormente.

Tomado de aquí (una buena lectura introductoria)

ingrese la descripción de la imagen aquí

Desde la página SS64 en MKLink

ingrese la descripción de la imagen aquí


Comentarios sobre terminología

Las uniones son enlaces simbólicos

Las uniones y los enlaces simbólicos realmente están haciendo lo mismo de la misma manera (puntos de análisis), aparte de las diferencias antes mencionadas en cómo se procesan. De hecho, técnicamente, un cruce es un enlace simbólico, y a veces la documentación puede llamar a un cruce un enlace simbólico, como es el caso aquí . Entonces, eso es algo a tener en cuenta con respecto a la terminología.

NTFS

Aunque el OP especifica esto, vale la pena señalar que "enlace simbólico" es un término muy general que no es específico de NTFS. Por lo tanto, para ser específicos, esta comparación es sobre NTFS Junctions vs. NTFS Symbolic Links.


3
¿Alguien probó la velocidad de procesamiento de Junctions vs Symbolic Links?
1000Gbps

El cuadro de pros / contras fue extremadamente útil, ¡gracias!
GordonM
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.