WIndows 10 e problemas de links simbólicos

6

Eu tenho uma configuração de dual boot composta pelo Windows 7 e Windows 10. Ambos estão configurados como C: disk as system e D: as data disk, que inclui o diretório Users. E eu também tenho outro disco (físico, também!), Vamos chamá-lo de V :, com fotos e outras coisas.

No Windows 7, para acessar fotos do disco D: Eu fiz um link simbólico (junção) como este (razões históricas):

mklink /j d:\photos v:\photos

E posso acessar totalmente todas as pastas em d: \ photos. Então eu tentei fazer o mesmo no Windows 10, mas não está funcionando corretamente como eu queria. Eu posso entrar no d: \ photos, mas nenhum outro subdiretório é acessível, nem eu posso escrever qualquer coisa dentro de d: \ photos. Mas eu posso acessar v: \ fotos sem problemas ...

Se eu clicar no Windows Explorer por ex. d: \ photos \ folder1, recebo "O sistema não pode mover o arquivo para uma unidade diferente". Se eu verificar a guia de segurança nessa pasta, localizarei a mensagem "As informações de segurança solicitadas estão indisponíveis ou não podem ser exibidas".

Eu já tentei algumas coisas, mas sem sucesso. Pode ser o problema que C: e D: estão no mesmo SSD, e V: é outro HD? Alguma idéia do que fazer?

Obrigado!

    
por Sajmon 25.01.2016 / 21:16

4 respostas

3

Embora as junções sejam suportadas nas unidades locais, você provavelmente terá mais sorte com os links simbólicos de diretórios reais. O Win7 (tudo desde o Vista, mais especificamente) suporta isso, embora o XP e o antigo não o suportem. Os links simbólicos armazenam nomes de destino reais (portanto, contanto que a outra unidade seja V: em ambos os sistemas operacionais, ela deve funcionar). Meu melhor palpite é que as junções podem usar um identificador diferente da letra da unidade e, quando você alterna os sistemas operacionais, alguns desses dados de identificação não são compreendidos pelo outro sistema operacional. Eles obviamente não usam apenas o nome, ou você seria capaz de fazer uma junção com uma unidade de rede mapeada, e você não pode.

A sintaxe para criar um verdadeiro symlink para um diretório é o mesmo que criar uma junção, exceto usar o /D flag para mklink , em vez de /J . Note que, por padrão, somente Administradores podem criar links simbólicos (não sei por que isso é imposto por links simbólicos e não por junções, mas é melhor que isso). Portanto, inicie o Prompt de Comando como Admin (e sim, ele deve ser CMD ; mklink é um CMD interno, não seu próprio executável que pode ser chamado por, digamos, Powershell ) e tente mklink /d d:\photos v:\photos .

Note que você também pode usar mklink sem nenhum sinalizador para criar links simbólicos arquivo , ou com o /H flag para criar hard links em arquivos . Não é relevante aqui, já que você está tentando vincular diretórios ao invés de arquivos, mas informações potencialmente úteis para o futuro. A maioria das pessoas não sabe que o NTFS suporta hard links (desde ... Windows 2000, eu acho?) E links simbólicos (desde o Vista), mesmo que eles saibam sobre junções (que não são um link simbólico completo, ou você pode criar um para uma unidade de rede).

    
por 25.01.2016 / 21:31
1

Eu tive o mesmo problema; isso parece ser causado pela alteração do local de instalação dos aplicativos em outra unidade.

O que resolvi para mim foi configurar o local de salvamento de novos aplicativos de volta para C e reinicializar o prompt de comando (mantenha pressionada a tecla enquanto reiniciava) e excluindo "System Volume Information \ wpappsettings.dat" na unidade em questão. / p>     

por 03.07.2016 / 23:02
0

Tem o mesmo problema: tem disco C: (novo windows10) D: (antigo) E: (antigo)

Eu posso criar junção de diretório de D para C (para subpastas "Arquivos de Programas" etc.), mas não posso fazer o mesmo de E para D: junções criadas, mas não consigo ver o conteúdo e subpastas de arquivos com o mesmo erro.

Não entendo por que, mas tudo resolvido carregando Ubuntu e excluindo "D: \ System Volume Information" (Foi recriado por Win10 depois).

PS. Tem resultado normal fsutil behavior query symlinkevaluation : local para * ativado, remoto para * desativado

    
por 21.06.2016 / 20:38
0

Eu me deparo com um problema semelhante um tempo antes que foram causados pelo sistema de permissão. No meu caso, eu tinha um unc-path como target, as permissões e o compartilhamento tinham sido configurados corretamente. Na unc-path consegui criar links e mergulhar em subpastas, na pasta simbólica não. Herdar direitos das pastas principais foi o motivo.

Tente desativar as permissões hereditárias da pasta simbólica e remover permissões que possam causar problemas. Definir permissões explícitas para obter controle total na pasta simbólica. No meu caso, resolveu os problemas e eu consegui criar links e mergulhar nas subpastas.

    
por 21.06.2016 / 22:33