Apenas mencionando um truque que não vejo mencionado aqui ainda.
Pegue este arquivo por exemplo:
C:\Folder1\Really Long Path\Such Recursion\So Deep\Wow\Still Going\I will run out of ideas soon\I have organizational problems\Obsessive compulsive subdirectory disorder\Here is a guid for no good reason\936DA01F-9ABD-4d9d-80C7-02AF85C822A8\Almost there\Tax Returns\2013\2013_tax_return.pdf
O caminho completo do arquivo tem 290 caracteres. O shell (Windows Explorer) e a maioria dos utilitários de linha de comando provavelmente não permitirão que você toque nele.
Use o subst
comando da seguinte maneira:
subst X: "C:\Folder1\Really Long Path\Such Recursion\So Deep\Wow"
Agora você pode acessar (e excluir, mover, etc.) o arquivo assim:
X:\Still Going\I will run out of ideas soon\I have organizational problems\Obsessive compulsive subdirectory disorder\Here is a guid for no good reason\936DA01F-9ABD-4d9d-80C7-02AF85C822A8\Almost there\Tax Returns\2013\2013_tax_return.pdf
E agora que o nome do arquivo tem apenas ~ 235 caracteres, você não encontrará mais os problemas "O nome do arquivo é muito longo".
Na API do Windows, há uma constante infame conhecida como MAX_PATH
. MAX_PATH tem 260 caracteres. O sistema de arquivos NTFS, na verdade, suporta caminhos de arquivo de até 32.767 caracteres. E você ainda pode usar nomes de caminho longos com 32.767 caracteres acessando as versões Unicode (ou "ampla") das funções da API do Windows e também prefixando o caminho com \\?\
.
MAX_PATH
foi gravado há muito tempo no mundo Windows. Eu acho que tem algo a ver com os padrões ANSI na época ... mas é uma daquelas coisas que é muito difícil para a Microsoft mudar agora, já que agora temos milhares de programas e aplicativos, incluindo alguns escritos pela própria Microsoft, que usam MAX_PATH
e falharia de maneiras novas e estranhas se a constante fosse subitamente alterada. (Estouros de buffer, corrupção de heap, etc.)