Directory Junction continua sendo excluído

Question

Eu atualizei do Windows 7 para o 10 Professional em um SSD e criei junções de diretório, usando a linha de comando mklink /J , para pastas como Games, Mozilla Profiles, etc. apontando para um diretório de HDD. Todas as junções funcionam bem, exceto pelo perfil do Mozilla Firefox, que é vinculado assim:

Junction created for C:\Users\[USERNAME]\AppData\Roaming\Mozilla <<===>> H:\Users\[USERNAME]\AppData\Roaming\Mozilla

Embora essa junção funcione bem quando criada, em intervalos aleatórios ela está sendo excluída. Após a inatividade do computador, a junção está ausente ou após uma reinicialização ou a qualquer momento durante o uso do computador. Isso não acontece toda vez que eu reinicio o computador ou o coloco em repouso, etc. Parece ser completamente aleatório.

Eu tentei também o link Directory Symbolic ( mklink /D ), mas o mesmo acontece. Curiosamente, não enfrento problemas com as outras junções no mesmo volume H:

Não há problemas com permissões de NTFS e o volume H: é um disco rígido fixo (não um removível).

Alguma idéia do que está causando isso?

    

Answer 1

PortableApps está causando a exclusão da junção, mas o problema está no comando rmdir do Windows. De acordo com este tópico no fórum PortableApps , todos os aplicativos empacotados no formato PortableApps contam com rmdir para remover quaisquer pastas que possam ter ficado criado pelo aplicativo portátil. rmdir pode remover uma pasta vazia, fornecerá um erro se a pasta não estiver vazia, mas quando usada contra uma junção apenas apaga a junção em si.

Aplicativos portáteis que usam a pasta AppData\Roaming\Mozilla , remova a junção quando estiver fechada. Esses aplicativos portáteis incluem Seamonkey, Firefox Developer Edition, Firefox, etc.

Atualmente, parece não haver solução ou solução alternativa para esse problema no lado do PortableApps. No entanto, há uma coisa que pode ser feita para impedir que a junção seja excluída. Em vez de criar uma junção ( mklink /j ), podemos criar um link simbólico ( mklink /d ) e, em seguida, editar as permissões de NTFS no symlink, adicionando Everyone Deny Full. Eu criei essa solução depois de ler o este thread SU .

    

Answer 2

Consegui resolver o problema desativando o Fast Startup no Power Options do Windows 10 Control Panel. É difícil encontrar; procure por "Alterar o que o botão liga / desliga faz" na margem esquerda do painel de controle da versão antiga. Uma vez encontrado, afirma ser apresentado em:

Control Panel > All Control Panel Items > Power Options > System Settings

Paraficarclaro,parecequenasversõesrecentesdoWindows10,chkdsk.exeéacionadodurantedeterminadoscenáriosdereinicialização(?).Paraomeucaso,issofezcomquetodososmeusNTFSrecupersepoints("junções de diretório") de volumes cruzados NTFS permanentes e manualmente definidos fossem excluídos en masse .

A configuração padrão para Fast Startup foi alterada para 'enabled' na Creators Update 1709 , que, pelo menos no meu caso, pode explicar como o problema nunca visto antes foi introduzido. Consulte aqui para mais informações.

Parece que o culpado real pode ser chkdsk.exe em si, independentemente do cenário de desencadeamento, "Início rápido" ou outro. É verdade - e simples de demonstrar - que executar explicitamente chkdsk.exe em um determinado volume NTFS parece remover completamente todos os pontos de nova análise de volume cruzado. Ou pelo menos para aqueles estabelecidos usando a notação do caminho \?\Volume{a6f7f7de-091e-4234-81a0-947ebba1bf3c}\ , que é tudo que eu uso para esses e, portanto, tudo o que posso relatar aqui:

Create a cross-volume Hard Link, e.g.

X:\foo> linkd bar \?\Volume{ce775273-ab33-47af-8fac-1abdb60a0690}\baz

Isso estabelece um link físico de volume cruzado ("junção" ou "ponto de nova análise NTFS") em que X:\foo\bar é redirecionado para que seja igual ao diretório \baz no volume especificado, mas esses links serão excluídos sempre chkdsk.exe é executado subseqüentemente no volume NTFS de origem X: