¿Por qué las versiones posteriores de Windows continúan usando archivos de acceso directo en lugar de enlaces simbólicos?

Windows XP y versiones posteriores admiten enlaces simbólicos. Sin embargo, Windows continúa utilizando archivos de acceso directo (que esencialmente almacenan la ubicación del archivo vinculado como texto). ¿Por qué?

windows links

— Alex
fuente

¿Por qué las nuevas versiones de Windows (y Office) guardan archivos de texto en formato ANSI y no UTF-8? Ya sea para perpetrar incompatibilidad e irracionalidad o para soportar sistemas heredados ...

— retrografía

Windows XP y posterior admiten simbólica en ciertos sistemas de archivos. Los enlaces simbólicos funcionan en un sistema de archivos NTFS en su disco duro, pero no funcionan si se copian a una memoria USB formateada con FAT 32 normal, o un CD-ROM con formato UDF, y pueden no funcionar si se copian a un servidor de red (como usted a menudo no conozco el sistema operativo o el sistema de archivos utilizado por el servidor remoto). Los archivos de acceso directo de LNK se pueden copiar felizmente y funcionan en todos ellos.

— GAThrawn

Los .lnkarchivos de Windows son más similares a los .desktoparchivos de Linux que a los enlaces simbólicos.

— Arturo Torres Sánchez

Los enlaces simbólicos son complicados con respecto a la seguridad (problema adjunto confuso)

— CodesInChaos

Entonces, ¿dejó de usar marcadores en su navegador cuando apareció NTFS? Puede parecer una comparación absurda, pero solo si cree que los atajos no son más que punteros a los archivos, ese simplemente no es el caso.

— Luaan

Respuestas:

106

Una serie de razones, supongo

Puede almacenar diferentes niveles de compatibilidad con varios accesos directos diferentes al mismo EXE tal como los interpreta el shell, en lugar del sistema de archivos.
Ciertos enlaces de acceso directo en realidad no existen en el sistema de archivos. Algunos de ellos son simplemente referencias a GUID o cadenas especiales interpretadas por el shell.
No puede incluir interruptores en un enlace simbólico. Puede señalar el EXE, claro, pero no puede decirle a ese EXE ningún argumento adicional.
No puede elegir un icono para un enlace simbólico.
No puede elegir desde qué directorio trabajar en un enlace simbólico.
Los archivos de acceso directo no solo tienen que apuntar a los archivos, sino que pueden ser hipervínculos o enlaces de protocolo (en el caso de un archivo .URL).
Los archivos LNK pueden existir en cualquier sistema de archivos. Los enlaces simbólicos son manejados por el propio sistema de archivos, en el caso de Windows, NTFS.
No hay necesidad real de reemplazarlos. Funcionan, son pequeños, se pueden ampliar en el futuro en caso de que sea necesario agregarles más funcionalidades que las mencionadas anteriormente.
Se requieren derechos administrativos para crear un enlace simbólico (por una buena razón; de lo contrario, la redirección de archivos inocentes a archivos maliciosos se puede ejecutar con muy poco trabajo)

No habrá más razones que esto, pero creo que es suficiente para empezar :) - Hay un enlace proporcionado por @grawity aquí que le dará una lectura más en las partes de este tema.

— Jonno
fuente

Además, los accesos directos de archivos almacenan en caché ciertos metadatos sobre el objetivo, y su interpretación a nivel de shell permite que los accesos directos sean actualizados por el shell si el objetivo se ha movido, lo que sería más difícil con los enlaces simbólicos. En general, vea Old New Thing nuevamente para ver varias cosas interesantes sobre las funciones de acceso directo.

— Grawity

@grawity Sin embargo, ¿habría algún beneficio importante para que estos sean manejados por el sistema de archivos? Pensé que los archivos .lnk tienen un espacio infinito para expandirse para una mayor funcionalidad si es necesario, al tiempo que conservan la compatibilidad con versiones anteriores, y no tienen mucha sobrecarga. ¿Mover esto al sistema de archivos sería un poco sobre diseñado, tal vez? Sin embargo, de ninguna manera soy un experto en el funcionamiento interno de los sistemas de archivos.

— Jonno

Es cierto que el FS en sí mismo no tendría uso para la mayoría de esta información: muchas características .lnk son realmente específicas del Explorador, por lo que almacenar todo como un punto de análisis en lugar de un archivo sería excesivo.

— Grawity

Solo quería señalar que, hasta donde yo sé, los archivos LNK no pueden usarse para orientar URL (hipervínculos). Puede usar la misma función de creación de accesos directos en Windows para crear un acceso directo a una URL, pero el resultado final es un archivo .URL (que es texto sin formato, esencialmente un archivo INI), no un archivo .LNK (que es binario).

— Michael Becker

O start http://superuser.comque elige el navegador predeterminado, como lo haría un verdadero acceso directo a una URL. Dicho esto, puede hacer que los archivos .LNK apunten a las URL. Al final, son "monikers COM serializados", y el sistema COM se puede ampliar con nuevos tipos de moniker.

— MSalters

Un enlace simbólico no es más que una ruta envuelta en una cantidad muy pequeña de magia del sistema de archivos. Hay varias formas en que puede volverse inválido ("roto"), la mayoría de las cuales implican el cambio de nombre de uno o más archivos o directorios. Como Windows es un software de consumo, es posible que tenga una gran cantidad de programas muy mal diseñados que se ejecutan en una instalación "típica". Como resultado, este tipo de rotura es mucho más difícil de evitar que en un servidor donde (en teoría) cada programa que toca el disco es una cantidad conocida.

Los atajos son inmunes a la mayoría de las formas de rotura ya que rastrean sus objetivos independientemente de la ruta. Esto los hace más fáciles de usar. Están diseñados específicamente para los consumidores, con un enfoque de "solo haz lo que quiero decir y no me molestes por los detalles".

Ahora, podría usar enlaces duros para eso (hasta cierto punto), pero los enlaces duros tienen una serie de propiedades complicadas que los hacen inadecuados para el uso del consumidor. En particular, los archivos obtienen nuevos números de inodo con demasiada facilidad y algunos softwares de respaldo se rompen espectacularmente cuando se enfrentan con enlaces duros. El primero podría (quizás) resolverse con la tunelización del sistema de archivos (que de hecho es cómo los atajos resuelven un problema relacionado), pero el último es un problema mucho más difícil.

(Probablemente también debería tener en cuenta que "resolver" los enlaces duros con túneles es decididamente no trivial, ya que no es solo una cuestión de volver a unir los metadatos que se "perdieron". o reasignarlos después del hecho sin un poco de trabajo preliminar. Dado que los accesos directos usan otros metadatos que se pueden tunelizar fácilmente, como el tiempo de creación, no tienen este problema).

— Kevin
fuente