Se você trabalha com o Windows por tempo suficiente, especialmente com pastas e arquivos com nomes longos, você se deparará com um erro bizarro: o Windows relatará que o caminho da pasta ou nome do arquivo é muito longo para mover para um novo destino ou até mesmo excluir. Qual é o problema?
Ei, How-To Geek!
Então, outro dia, eu estava reorganizando alguns arquivos no meu computador, criando pastas, esse tipo de coisa. Então, quando estava movendo alguns arquivos para uma pasta, recebo uma mensagem informando que o caminho da pasta resultante seria muito longo. Eu estava confuso. Eu sei que todos os sistemas operacionais, desde o DOS, oferecem suporte a nomes de arquivos longos, mas o Windows afirma que o caminho é muito longo. Por que isso acontece?
Sinceramente,
Senhor desorganizado
O problema que você está enfrentando é uma infeliz interseção de dois sistemas que, em casos como esse, produz um erro. Para entender exatamente de onde vem o erro, precisamos nos aprofundar na história dos nomes de arquivos longos (LFN) e como o Windows interage com eles antes de nos aprofundarmos nas soluções.
Nomes de arquivos longos foram introduzidos, por meio da arquitetura subjacente do MS-DOS, no Windows 95. O novo sistema LFN permitia nomes de arquivos e diretórios de até 255 caracteres. Esta foi uma expansão bem-vinda do sistema de nome de arquivo anterior, geralmente chamado de 8.3 filenaming porque o nome era limitado a oito caracteres e uma extensão de três dígitos, mas também conhecido como Short Filename (SFN). Como você pode imaginar, naquela época ainda havia muitos aplicativos baseados em DOS por aí e havia mais do que algumas dores de cabeça tentando fazer com que os LFNs mais novos e os SFNs legados funcionassem bem uns com os outros. Se você já encontrou um disquete ou CD-ROM mais antigo com arquivos estranhamente truncados (como abcdef ~ 1.txt), esse nome de arquivo foi cortado por algum aplicativo legado usando SFN de algum LFN mais longo e sem suporte (como abcdefghijk. TXT).
Estamos muito longe de meados da década de 1990, entretanto, e toda a coisa do Long Filename está (na maior parte) firmemente resolvida. Se você está executando uma versão do Windows dos últimos 10 anos, provavelmente nunca se deparou com um conflito de comprimento de nome de arquivo como costumávamos encontrar nos dias do DOS / Windows 95. Dito isso, ainda temos soluços, como você descobriu em seu projeto de limpeza de disco. Mas por que? Se o sistema de nomes de arquivo longos do Windows oferece suporte a nomes de arquivos e pastas de até 255 caracteres por componente, que parede você está enfrentando? Não podemos culpar o NTFS (o sistema de arquivos que a grande maioria das máquinas Windows modernas usa), pois o NTFS suportará um encadeamento de pastas e nomes de arquivos com um comprimento total de caminho de 32.767 caracteres. Isso excede em muito a estrutura de diretório típica que a maioria dos usuários jamais precisaria.
Onde tudo desmorona é uma restrição artificial que o Windows empilha em cima do sistema LFN / NTFS: a variável MAX_PATH. A variável MAX_PATH especifica que uma estrutura de diretório completa no Windows não pode exceder 260 caracteres no total, incluindo a letra da unidade, dois pontos, barra invertida e barra invertida nula no final. Assim, você só tem um potencial MAX_PATH real de 256 caracteres, por exemplo, C: \ your-256-character-path \ .
Então, o que aconteceu quando você estava limpando seu computador é que você tinha um diretório com um caminho já longo (porque os nomes das pastas eram longos, os nomes dos arquivos eram longos, ou ambos), e quando você tentou mover um ou mais dos esses diretórios em outro diretório com um caminho longo, o comprimento total do nome do caminho excedeu o limite de 260 caracteres imposto pela variável MAX_PATH.
Agora, você pode estar pensando “Ah-hah! Vamos apenas mudar a variável MAX_PATH e resolver o problema! ” Infelizmente, não é tão simples. Não apenas a variável MAX_PATH é essencialmente codificada no Windows, mas mesmo que você passasse pelo enorme incômodo de alterá-la, acabaria quebrando tanto que não valeria a pena. Muitos aplicativos esperam que a variável de caminho seja o que o Windows especificou há muito tempo. Não podemos simplesmente mudar isso sem criar uma bagunça enorme.
Onde isso deixa você? Bem, a solução mais simples é apenas editar os dados do caminho. Por exemplo, se você tiver uma tonelada de artigos salvos em que o aplicativo / extensão usado para salvá-los da web criou um diretório que era o título completo do artigo + o cabeçalho do artigo, e então o nome do arquivo em si é o título completo do artigo + o lead do artigo, seria realmente simples atingir ou exceder MAX_PATH com um único salvamento. Editar essas enormes pastas e títulos de artigos para um tamanho mais razoável é uma maneira fácil de resolver o problema.
Se você tiver um grande número de arquivos com um caminho longo e não quiser editá-los todos (ou se quiser excluir uma tonelada de diretórios antigos que são muito longos para o Windows lidar quando restrito pela variável MAX_PATH) , há uma solução alternativa para a linha de comando. Mesmo que o Windows seja restringido pela variável MAX_PATH, os engenheiros do Windows perceberam que haveria situações em que os usuários precisariam lidar com nomes de caminho mais longos. Como tal, a API do Windows tem uma função para lidar com caminhos extremamente longos.
Para tirar proveito dessa API e usar ferramentas de linha de comando em seus nomes de pastas / arquivos complicados, você simplesmente precisa acrescentar alguns caracteres extras ao nome do diretório. Por exemplo, se você tivesse uma estrutura de diretório enorme que deseja excluir (mas recebeu um erro devido ao comprimento do caminho quando tentou), você poderia alterar o comando de:
rmdir c:\documents\some-really-super-long-folder-name-scheme\
para:
rmdir \\?\c:\documents\some-really-super-long-folder-name-scheme\
A chave é a adição da \\?\parte antes do início do caminho do arquivo; isso instrui o Windows a desconsiderar as limitações impostas pela variável MAX_PATH e a interagir com o caminho que você acabou de fornecer conforme fornecido / entendido diretamente pelo sistema de arquivos subjacente (que pode claramente suportar um caminho mais longo). Como sempre, tenha cuidado no prompt de comando para evitar a exclusão acidental de arquivos ou diretórios que você pretendia deixar intactos.
Se a nossa visão geral deste problema o deixou curioso, com certeza vá fundo neste artigo da biblioteca do Microsoft Developer Network, Naming Files, Paths e Namespaces , para obter mais informações sobre o que está acontecendo nos bastidores.
Tem uma questão técnica urgente? Envie-nos um e-mail para ask@howtogeek.com e faremos o nosso melhor para responder.
