mklink para compartilhamento de rede ou caminho UNC ou unidade mapeada?

5

Há desempenho, permissão ou outras considerações a serem consideradas ao usar um caminho mklink em um compartilhamento de rede, em vez de apenas um caminho UNC reto (ou uma unidade mapeada para esse assunto).

Por exemplo, essas três maneiras de acessar um recurso de rede podem ser consideradas funcionalmente equivalentes e mais ou menos intercambiáveis?

mklink /d c:\shares\warehouse \server1\warehouse
xcopy /s c:\shares\warehouse d:\temp\warehouse_copy

.

xcopy /s \server1\warehouse d:\temp\warehouse_copy

.

net use X: \server1\warehouse
xcopy /s X:\ d:\temp\warehouse_copy

Servidor é o Windows 2003, os clientes são o Win7 Pro. A rede é na maior parte gigabit, embora haja alguns laggards 100mbit aqui e ali. Eu usei um shell cmd no exemplo, porque é mais fácil de explicar, na prática, o recurso seria acessado por uma variedade de outros métodos também (Windows Explorer, Office "abrir" diálogos, serviços de backup do sistema, etc.)

    
por matt wilkie 30.09.2013 / 21:41

1 resposta

2

Recomendamos strongmente que NÃO use links simbólicos que tenham um destino remoto. Meu raciocínio é que um link simbólico faz uma entrada na tabela de arquivos mestre do NTFS e, embora não substanciado, eu acho que isso poderia causar problemas ao executar operações MFT NTFS de baixo nível (como um CHKDSK off-line).

Quanto ao desempenho, não vejo que houvesse qualquer diferença. Ambos resultam em tráfego SMB. A rota do link simbólico tem que passar por um redirecionamento (manipulado pelo NTFS.SYS), mas a "latência" aqui será milhares de vezes menor que qualquer atraso subseqüente na rede ...

    
por 30.09.2013 / 22:17