Por que versões posteriores do Windows continuam a usar arquivos de atalho em vez de links simbólicos?

Question

O Windows XP e posteriores suportam links simbólicos. No entanto, o Windows continua a usar arquivos de atalho (que basicamente armazenam o local do arquivo vinculado como texto). Por quê?

    

Answer 1

Vários motivos, eu acho

1. Você pode armazenar diferentes níveis de compatibilidade com vários atalhos diferentes para o mesmo EXE, conforme forem interpretados pelo shell, em vez do sistema de arquivos.
2. Certos links de atalho não existem no sistema de arquivos. Alguns deles são simplesmente referências a GUIDs ou strings especiais interpretadas pelo shell.
3. Você não pode incluir opções em um link simbólico. Você pode apontar para o EXE, com certeza, mas você não pode dizer ao EXE mais argumentos.
4. Você não pode escolher um ícone para um link simbólico.
5. Você não pode escolher em qual diretório trabalhar em um symlink.
6. Arquivos de atalho não precisam apenas apontar para arquivos, eles podem ser hyperlinks ou links de protocolo (no caso de um arquivo .URL).
7. Arquivos LNK podem existir em qualquer sistema de arquivos. Os links simbólicos são manipulados pelo próprio sistema de arquivos, no caso do Windows, NTFS.
8. Não há necessidade real de substituí-los. Eles funcionam, são minúsculos, podem ser ampliados no futuro, caso haja necessidade de mais funcionalidades para serem adicionados a eles do que os listados acima.
9. Os direitos administrativos são necessários para criar um link simbólico (por um bom motivo - caso contrário, o redirecionamento de arquivos inocentes para arquivos maliciosos pode ser executado com muito pouco trabalho)

Haverá mais razões do que isso, mas acho que é o suficiente para você começar :) - Existe um link fornecido pelo @grawity aqui que dará algumas leituras adicionais sobre partes deste tópico.

    

Answer 2

Um link simbólico nada mais é do que um caminho embrulhado em uma quantidade muito pequena de magia do sistema de arquivos. Existem várias maneiras de se tornar inválidas ("quebradas"), a maioria das quais envolve um ou mais arquivos ou diretórios sendo renomeados. Como o Windows é um software para o consumidor, você pode ter um grande número de programas mal projetados em execução em uma instalação "típica". Como resultado, esse tipo de quebra é muito mais difícil de evitar do que em um servidor onde (em teoria) cada programa que toca o disco é uma quantidade conhecida.

Os atalhos são imunes à maioria das formas de quebras , pois rastreiam seus alvos independentemente de caminho. Isso os torna mais fáceis de usar. Eles são projetados especificamente para os consumidores, com uma abordagem "apenas faça o que eu quero dizer e não me incomoda sobre os detalhes".

Agora, você pode usar links físicos para isso (até certo ponto), mas links físicos têm um número de propriedades complicadas que as tornam inadequadas para uso do consumidor. Em particular, os arquivos obtêm novos números de inode com muita facilidade e alguns softwares de backup quebram de forma espetacular quando se deparam com hard links. O primeiro poderia (talvez) ser resolvido com o tunelamento do sistema de arquivos (que, na verdade, é atalhos resolvem um problema relacionado), mas o último é um problema muito mais difícil.

(Eu provavelmente também notaria que "resolver" hard links com tunelamento é decididamente não-trivial já que não é apenas uma questão de reconectar metadados que "se perderam". Inodes estão ligados no esquema de alocação de disco, então você não pode apenas mesclar ou reatribuir arbitrariamente após o fato sem um bocado de legwork. Como os atalhos usam outros metadados que podem ser facilmente tunelados, como o tempo de criação, eles não têm esse problema.)