Por que o limite de comprimento do caminho de 260 caracteres existe no Windows?

Eu já enfrentei esse problema algumas vezes em momentos inoportunos:

• Tentando trabalhar em projetos Java de código aberto com caminhos profundos
• Armazenando árvores wiki profundas do Fitnesse no controle de origem
• Erro ao tentar usar o Bazaar para importar minha árvore de controle de origem

Por que esse limite existe?

Por que ainda não foi removido?

Como você lida com o limite de caminho? E não, mudar para Linux ou Mac OS X não é uma resposta válida para esta pergunta;)

Citando este artigo https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Limitação máxima de comprimento do caminho

Na API do Windows (com algumas exceções discutidas nos parágrafos a seguir), o comprimento máximo de um caminho é MAX_PATH , definido como 260 caracteres. Um caminho local é estruturado na seguinte ordem: letra da unidade, dois pontos, barra invertida, componentes de nome separados por barras invertidas e um caractere nulo final. Por exemplo, o caminho máximo na unidade D é "D: \ alguma cadeia de caracteres de 256 caracteres <NUL>", em que "<NUL>" representa o caractere nulo final invisível para a página de códigos atual do sistema. (Os caracteres <> são usados ​​aqui para maior clareza visual e não podem fazer parte de uma cadeia de caminho válida.)

Agora vemos que é 1 + 2 + 256 + 1 ou [drive] [: \] [path] [null] = 260. Pode-se supor que 256 seja um comprimento de cadeia fixo razoável dos dias do DOS. E voltando às APIs do DOS, percebemos que o sistema rastreava o caminho atual por unidade e temos 26 (32 com símbolos) unidades máximas (e diretórios atuais).

O INT 0x21 AH = 0x47 diz "Esta função retorna a descrição do caminho sem a letra da unidade e a barra invertida inicial". Portanto, vemos que o sistema armazena o CWD como um par (unidade, caminho) e você solicita o caminho especificando a unidade (1 = A, 2 = B,…); se você especificar um 0, assumirá o caminho para a unidade retornada por INT 0x21 AH = 0x15 AL = 0x19. Então agora sabemos por que é 260 e não 256, porque esses 4 bytes não são armazenados na cadeia de caminho.

Por que uma string de caminho de 256 bytes, porque 640K é RAM suficiente.

Isso não é rigorosamente verdadeiro, pois o sistema de arquivos NTFS suporta caminhos com até 32k caracteres. Você pode usar a API win32 e " \\?\" prefixar o caminho para usar mais de 260 caracteres.

Uma explicação detalhada do caminho longo no blog da equipe .Net BCL .
Um pequeno trecho destaca a questão com caminhos longos

Outra preocupação é o comportamento inconsistente que resultaria expondo o suporte a longo caminho. Caminhos longos com o \\?\prefixo podem ser usados ​​na maioria das APIs do Windows relacionadas a arquivos, mas não em todas as APIs do Windows. Por exemplo, LoadLibrary, que mapeia um módulo para o endereço do processo de chamada, falha se o nome do arquivo for maior que MAX_PATH. Portanto, isso significa que o MoveFile permitirá que você mova uma DLL para um local com um caminho maior que 260 caracteres, mas quando você tenta carregar a DLL, ela falha. Existem exemplos semelhantes nas APIs do Windows; existem algumas soluções alternativas, mas elas são caso a caso.

A questão é por que a limitação ainda existe. Certamente o Windows moderno pode aumentar o lado MAX_PATHpara permitir caminhos mais longos. Por que a limitação não foi removida?

• A razão pela qual não pode ser removido é que o Windows prometeu que nunca mudaria.

Através do contrato de API, o Windows garantiu a todos os aplicativos que as APIs de arquivo padrão nunca retornarão um caminho mais longo que os 260caracteres.

Considere o seguinte código correto :

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

O Windows garantiu ao meu programa que ele preencheria minha WIN32_FIND_DATAestrutura:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

Meu aplicativo não declarou o valor da constante MAX_PATH, a API do Windows fez. Meu aplicativo usou esse valor definido.

Minha estrutura está definida corretamente e aloca apenas o 592total de bytes. Isso significa que eu só consigo receber um nome de arquivo com menos de 260caracteres. O Windows me prometeu que, se eu escrevesse meu aplicativo corretamente, ele continuaria funcionando no futuro.

Se o Windows permitir nomes de arquivos com mais de 260caracteres, meu aplicativo existente (que usou a API correta corretamente) falhará.

Para quem pede que a Microsoft altere a MAX_PATHconstante, primeiro é necessário garantir que nenhum aplicativo existente falhe. Por exemplo, eu ainda possuo e uso um aplicativo do Windows que foi escrito para ser executado no Windows 3.11. Ele ainda roda no Windows 10. de 64 bits. É isso que a compatibilidade com versões anteriores oferece.

Microsoft fez criar uma maneira de usar o total de 32.768 nomes de caminho; mas eles tiveram que criar um novo contrato de API para fazer isso. Por um lado, você deve usar a API do Shell para enumerar arquivos (como nem todos os arquivos existem em um disco rígido ou em um compartilhamento de rede).

Mas eles também precisam não quebrar os aplicativos de usuário existentes. A grande maioria dos aplicativos não usa a API do shell para o trabalho do arquivo. Todo mundo simplesmente liga FindFirstFile/ FindNextFilee liga por dia.

No Windows 10. você pode remover a limitação modificando uma chave do Registro.

Dica A partir do Windows 10, versão 1607, as limitações MAX_PATH foram removidas das funções comuns de arquivo e diretório do Win32. No entanto, você deve aceitar o novo comportamento.

Uma chave do Registro permite ativar ou desativar o novo comportamento do caminho longo. Para habilitar o comportamento do caminho longo, defina a chave do Registro em HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(Tipo REG_DWORD:). O valor da chave será armazenado em cache pelo sistema (por processo) após a primeira chamada para um arquivo Win32 ou função de diretório afetada (lista a seguir). A chave do registro não será recarregada durante a vida útil do processo. Para que todos os aplicativos no sistema reconheçam o valor da chave, uma reinicialização pode ser necessária porque alguns processos podem ter sido iniciados antes da configuração da chave. A chave do registro também pode ser controlada via Diretiva de Grupo em Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths. Você também pode habilitar o novo comportamento de caminho longo por aplicativo por meio do manifesto:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Você pode montar uma pasta como uma unidade. Na linha de comando, se você tiver um caminho, C:\path\to\long\folderpoderá mapeá-lo para a letra da unidade X:usando:

subst x: \path\to\long\folder

Uma maneira de lidar com o limite do caminho é encurtar as entradas do caminho com links simbólicos.

Por exemplo:

1. crie um C:\pdiretório para manter links curtos para caminhos longos
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. adicione C:\p\fooao seu caminho em vez do caminho longo

Você pode habilitar nomes de caminhos longos usando o PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

Outra versão é usar uma Diretiva de Grupo em Computer Configuration/ Administrative Templates/ System/ Filesystem:

Por que isso ainda existe - a MS não considera prioritária e valoriza a compatibilidade com versões anteriores do avanço do sistema operacional (pelo menos nesse caso).

Uma solução alternativa que eu uso é usar os "nomes abreviados" para os diretórios no caminho, em vez de suas versões padrão legíveis por humanos. Então, por exemplo, para C:\Program Files\eu usar C:\PROGRA~1\ Você pode encontrar o nome abreviado equivalente dir /x.

Sobre como lidar com a limitação do tamanho do caminho no Windows - usar o 7zip para compactar (e descompactar) seus arquivos sensíveis ao comprimento do caminho parece uma solução viável. Usei-o para transportar várias instalações IDE (esses caminhos de plug-in do Eclipse, caramba!) E pilhas de documentação gerada automaticamente e não tive um único problema até agora.

Não tenho muita certeza de como ele foge do limite de 260 caracteres definido pelo Windows (de um PoV técnico), mas, ei, funciona!

Mais detalhes na página do SourceForge aqui :

"O NTFS pode realmente suportar nomes de caminho com até 32.000 caracteres."

O 7-zip também suporta nomes tão longos.

Mas está desativado no código SFX. Alguns usuários não gostam de caminhos longos, pois não sabem como trabalhar com eles. É por isso que eu o desativei no código SFX.

e notas de versão :

9.32 alpha 01-12-2013

• Suporte aprimorado para nomes de caminho de arquivos com mais de 260 caracteres.

4.44 beta 2007-01-20

• O 7-Zip agora suporta nomes de caminho de arquivos com mais de 260 caracteres.

NOTA IMPORTANTE: Para que isso funcione corretamente, você precisará especificar o caminho de destino na caixa de diálogo 7zip "Extrair" diretamente, em vez de arrastar e soltar os arquivos na pasta pretendida. Caso contrário, a pasta "Temp" será usada como um cache intermediário e você retornará à mesma limitação de 260 caracteres quando o Windows Explorer começar a mover os arquivos para o "local de descanso final". Veja as respostas a esta pergunta para mais informações.

Sim, e é um padrão por algum motivo, mas você pode substituí-lo facilmente por esta chave do Registro:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Consulte: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Outra maneira de lidar com isso é usar o Cygwin, dependendo do que você deseja fazer com os arquivos (ou seja, se os comandos do Cygwin atenderem às suas necessidades)

Por exemplo, ele permite copiar, mover ou renomear arquivos que nem o Windows Explorer pode. Ou, é claro, lide com o conteúdo deles, como md5sum, grep, gzip, etc.

Também para os programas que você está codificando, você pode vinculá-los à DLL do Cygwin e permitir que eles usem caminhos longos (ainda não testei isso)