Crie um link simbólico relativo no Windows 10 para cópias de arquivos

0

Vou simplificar drasticamente tudo o que tentei. Para detalhes exatos, leia a captura de tela CMD .

Eu quero criar um link simbólico RELATIVE PATH chamado [ RESOURCES ] no seguinte caminho:

C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music 

Isso deve apontar para:

C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\{[ LONGCHAR REDIRECT ]}

Eu tenho tentado mklink /D em cmd como administrador, com as etapas a seguir.

  1. Navegue até o diretório no qual o link simbólico deve ser criado.

    cd "C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music"
    
  2. Crie o link simbólico.

    mklink /d "[ RESOURCES ]" "../../../{[ LONGCHAR REDIRECT ]}"
    symbolic link created for [ RESOURCES ] <<===>> ../../../{[ LONGCHAR REDIRECT ]}
    

Para o melhor do meu entendimento, esta sintaxe deve definir o link para {[ LONGCHAR REDIRECT ]} em [ SOURCE ] em relação a Music , mas isso não acontece!

A confirmação indica que o link foi criado com sucesso, mas quando tento acessar o link simbólico, recebo o seguinte erro:

cd "C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music\[ RESOURCES ]"
C:\Users\crack\Documents\[ GLOBAL ]\[ SOURCE ]\[ INITIATIVES ]\Audio\Music\[ RESOURCES ] is not accessible.  

The filename, directory name, or volume label syntax is incorrect.

Estou entendendo mal o uso de .. para indicar um diretório pai? Novamente, sinta-se à vontade para analisar minhas várias experiências por meio da captura de tela de CMD . Eu tentei várias variações no tema do caminho de arquivo relativo, usando .. , . e alterando o diretório atual.

Se mklink não implementar a associação desejada, sinta-se à vontade para recomendar uma alternativa relativa ao caminho do arquivo. Copio o diretório [ GLOBAL ] para várias unidades e serviços de backup, por isso preciso que os caminhos de arquivo truncados abaixo da limitação 260 MAX_PATH por meio de sua localização real na pasta {[ LONGCHAR REDIRECT ]} sejam refletidos em cada local duplicado, mas preciso meu diretório de trabalho para incluir seus locais virtuais na pasta [ RESOURCES ] .

    
por Stephen Hanson 31.05.2017 / 08:59

3 respostas

0

Em primeiro lugar, devemos analisar a sintaxe das opções e os parâmetros necessários gerados inserindo a solicitação de ajuda do comando mklink , mklink /? :

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

    /D      Creates a directory symbolic link.  Default is a file
            symbolic link.
    /H      Creates a hard link instead of a symbolic link.
    /J      Creates a Directory Junction.
    Link    Specifies the new symbolic link name.
    Target  Specifies the path (relative or absolute) that the new link
            refers to.

Atualmente, só é possível imbuir dados relativos de caminho de caminho nos links simbólicos do diretório.

Portanto, devemos usar o comando mklink em conjunto com a opção de comando ("soft link") mklink , /D , assim.

mklink /D . . .

O parâmetro mklink Target deve descrever um caminho de arquivo que inclua pelo menos um OPERADOR DE ARQUIVO RELATIVO como . ou .. em conjunto com quantos BACKSLASHES ( \ ) forem necessários pela hierarquia relativa de diretórios pai, bem como um " DOUBLE-QUOTED " filepath em qualquer caso em que um ou mais caracteres de espaços em branco são requeridos por um fragmento de caminho de campo ABSOLUTE filho do link para -bem-concatenado mklink Target filepath.

Para finalizar o comando

mklink /D "C:/Test Folder/Link Name With Spaces" . . .

substituindo o parâmetro mklink Target por

. . ..\"Target Name With Spaces"

ou

. . "..\Target Name With Spaces"

criará um destino de caminho relativo concatenado com sucesso em um link gerado em

C:/test foldEr/Link Name With Spaces

e terminando

mklink /D "C:/Test Folder/Test Folder 2/Link Name With Spaces" . . .

com

. . "..\..\Target Name With Spaces"

ou

. . ..\..\"Target Name With Spaces"

criará um link em

C:/Test Folder/Test Folder 2/Link Name With Spaces .

Em todos os quatro casos, o resultado final é um link simbólico de diretório que aponta para o diretório

C:/TaRget nAme WitH SpacEs ,

mas que apontará para um local diferente inteiramente se algum dos links gerados for movido para outro diretório por um comando como robocopy ou por um aplicativo que similarmente honre links simbólicos.

    
por 31.05.2017 / 09:25
1

Três coisas:

  1. não use links simbólicos a menos que seja absolutamente necessário, porque por padrão você precisa ser administrador para usá-los. Se você deseja vincular dirs localmente, use Junções, que também são suportadas por um usuário restrito padrão.

  2. Tente substituir o software que não suporta nomes longos de arquivos Unicode, o que é possível com bastante frequência. Esses nomes de arquivos longos estão disponíveis desde NTFS e Windows NT , então o software simplesmente deve suportá-lo e muitos frameworks / tempos de execução como o Java o fazem de fábrica. Software destinado a copiar coisas ou fazer backup de coisas, que não suporta nomes extensos de arquivos, está bastante quebrado e certamente tem outras limitações sérias também, especialmente no caso de backups. Pense em coisas como permissões, manipulação de diferentes links e tipos de arquivo corretamente, fluxos de dados alternativos etc. É preciso ter cuidado.

  3. A razão para o seu problema real parece ser diferenças em links simbólicos vs. Junções ou talvez diferenças em como os caminhos fornecidos pelo shell são analisados:

C:\Users\tschoening\Documents\test\target>mklink /J "[ target ]" "../src/{[ murks ]}"

Verbindung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

C:\Users\tschoening\Documents\test\target[ target ]>cd ..

C:\Users\tschoening\Documents\test\target>

Como você pode ver, acessar "[target]" dessa maneira funciona, enquanto o seguinte não funciona e gera o mesmo erro, como em alemão:

C:\Users\tschoening\Documents\test\target>mklink /D "[ target ]" "../src/{[ murks ]}"

symbolische Verknüpfung erstellt für [ target ] <<===>> ../src/{[ murks ]}

C:\Users\tschoening\Documents\test\target>cd "[ target ]"

Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

C:\Users\tschoening\Documents\test\target>

Pelo menos eu não vejo nenhuma outra diferença do que / J vs. / D no meu teste, mas posso estar faltando alguma coisa, é claro. Por isso, sugiro que você repita seu teste usando Junções.

Alguma coisa interessante adicional que acabei de reconhecer: Abrindo o link simbólico criado com a sintaxe acima em cmd.exe e o Windows Explorer falha diretamente, mas ele tem êxito no Link Shell Extension. Dê uma olhada na captura de tela a seguir, que mostra o caminho relativo. Clicar em "Ziel öffnen" abre uma nova pasta do Windows Explorer mostrando o destino do link. Parece que o Link Shell Extension está interpretando a si próprio e pode fornecer \ para a API do Windows subjacente? Algo que o próprio Windows não está fazendo, mas simplesmente usando / as são declarados no próprio link, o que é errado para os caminhos. Então, como o @Seth já reconheceu, o próprio / é o problema com os links simbólicos.

    
por 31.05.2017 / 09:41
1

Você está usando o tipo errado de barras se quiser se referir a um pai no diretório atual. Nesse caso, você precisa usar uma barra invertida. As barras de encaminhamento funcionam se você quiser apenas fazer referência a crianças. Com um caminho absoluto, isso não parece importar.

mkdir C:\temp\example\a
mkdir C:\temp\example\b\c
mklink /D C:\temp\example\a\redirection ..\b

Quanto ao limite de 260 caracteres, use um aplicativo que lide com ele, em vez de procurar uma solução facilmente quebrável ou encurtar seus caminhos.

    
por 31.05.2017 / 09:09