Eu tenho uma configuração de inicialização dupla composta por Windows 7 e Windows 10. Ambos estão configurados em um disco C: como sistema e D: como disco de dados, que inclui o diretório Usuários. E tenho também outro disco (físico também!), vamos chamar de V:, com fotos e outras coisas.
No Windows 7, para acessar fotos do disco D: fiz um link simbólico (junção) assim (motivos históricos):
mklink /j d:\photos v:\photos
E posso acessar totalmente todas as pastas em d:\photos. Tentei fazer o mesmo no Windows 10, mas não está funcionando corretamente como gostaria. Posso entrar em d:\photos, mas nenhum outro subdiretório está acessível nem posso escrever nada dentro de d:\photos. Mas consigo acessar v:\photos sem problemas...
Se eu clicar com o Windows Explorer ativado, por exemplo. d:\photos\folder1, recebo "O sistema não pode mover o arquivo para uma unidade diferente". Se eu verificar a guia de segurança dessa pasta, encontro a mensagem "As informações de segurança solicitadas estão indisponíveis ou não podem ser exibidas".
Já tentei algumas coisas, mas sem sucesso. Pode ser o problema de C: e D: estarem no mesmo SSD e V: estar em outro HD? Alguma ideia do que fazer?
Obrigado!
Responder1
Embora as junções sejam suportadas em unidades locais, você provavelmente terá mais sorte com links simbólicos de diretório reais. O Win7 (tudo desde o Vista, mais especificamente) suporta isso, embora o XP e versões anteriores não. Os links simbólicos armazenam nomes de destino reais (portanto, desde que a outra unidade esteja V:em ambos os sistemas operacionais, ela deverá funcionar). Meu melhoradivinharé que as junções podem usar um identificador diferente da letra da unidade e quando você troca de sistema operacional, alguns desses dados de identificação não são compreendidos pelo outro sistema operacional. Eles obviamente nãoapenasuse o nome, ou você poderá fazer uma junção para uma unidade de rede mapeada, mas não pode.
A sintaxe para criar um link simbólico verdadeiro para um diretório é a mesma da criação de uma junção, exceto pelo uso do /Dsinalizador for mklink, em vez de /J. Observe que, por padrão, apenas administradores podem criar links simbólicos (não sei por que isso é aplicado para links simbólicos e não para junções, mas é a vida). Portanto, inicie o Prompt de Comando como Admin (e sim, deve ser CMD; mklinké um CMD integrado, não seu próprio executável que poderia ser chamado por, digamos, Powershell) e tente mklink /d d:\photos v:\photos.
Observe que você também pode usar mklinksem sinalizadores para criararquivolinks simbólicos, ou com o /Hsinalizador para criar arquivolinks físicos. Não é relevante aqui, já que você está tentando vincular diretórios em vez de arquivos, mas informações potencialmente úteis para o futuro. A maioria das pessoas não sabe que o NTFS suporta links físicos (desde... Windows 2000, eu acho?) E links simbólicos (desde o Vista), mesmo que saibam sobre junções (que não são um link simbólico completo, ou você pode criar um para uma unidade de rede).
Responder2
Eu tive o mesmo problema; isso parece ser causado pela alteração do local de instalação dos aplicativos para outra unidade.
O que resolveu para mim foi definir o local de salvamento para novos aplicativos de volta para C e, em seguida, reinicializar no prompt de comando (segure shift ao reiniciar) e excluir "System Volume Information\wpappsettings.dat" na unidade em questão.
Responder3
Tem o mesmo problema: tem disco C:(novo windows10) D:(antigo) E:(antigo)
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 dos arquivos e subpastas com o mesmo erro.
Não entendo o porquê, mas tudo foi resolvido carregando o Ubuntu e excluindo "D:\System Volume Information" (foi recriado pelo Win10 depois).
PS. Tem resultado normal fsutil behavior query symlinkevaluation: local para * habilitado, remoto para * desabilitado
Responder4
Eu me deparei com um problema semelhante há algum tempo, causado pelo sistema de permissão. No meu caso eu tinha um caminho unc como destino, as permissões e o compartilhamento foram configurados corretamente. No unc-path consegui criar links e mergulhar em subpastas, na pasta simbólica não. Herdar direitos das pastas principais foi o motivo.
Tente desabilitar as permissões herdadas para a pasta simbólica e remover as permissões que podem causar problemas. Defina permissões explícitas para obter controle total na pasta simbólica. No meu caso resolveu os problemas e consegui criar links e mergulhar nas subpastas.