Esta pergunta foi feita, mas infelizmente nenhuma das sugestões funcionou.
Aqui está a situação: o arquivo é sincronizado com uma pasta local no meu computador na pasta / users do Google Drive. É um pdf (parece um recibo salvo de algum lugar). O nome tem > 255 caracteres, o que desativa o Windows.
O que o arquivo não fará
Na verdade, não consegui que o arquivo fornecesse qualquer tipo de resposta além do mesmo erro.
Soluções testadas:
dir /x --no nome curto é listado, ele simplesmente repete o nome normal. rmdir /S /Q <dir> não funciona realmente porque está na minha pasta de usuário ... Se alguém tiver uma ideia para tentar, eu estaria aberto a isso.
Edit - Neste caso, o próprio nome do arquivo é maior que 255 caracteres. Alterar os diretórios nos quais ele está aninhado não afetará o problema, pois não há problemas com o caminho do arquivo. (Esse problema por si só elimina muitas outras soluções).
Gostaria de inicializar em um Linux Live Disc , montar sua unidade do Windows e removê-lo usando o Linux / Unix.
Acho que os principais comandos de que você precisa são:
mount -t ntfs-3g /dev/sdX# /mnt
cd /mnt/Users/You
rm -f further/loc/away.filename
(Nota: você pode precisar executar fdisk -l para localizar sua partição do Windows)
e isso deve levá-lo até lá. Eu tive que fazer isso em algum momento no tempo também.
No Windows, basta usar o gerenciador de arquivos 7z ou qualquer outro aplicativo explorador (como) que use versões Unicode de API para manipulação de arquivos. Duplicados e mais informações:
( 1 ) Formação técnica do issue: O limite MAX_PATH (veja também (4)).
( 2 ) superar esse limite em um nível de programador.
( 3 ) Como superar esse limite um nível de usuário.
Por favor, esteja ciente de que (3) é APENAS uma solução alternativa. Não é de forma alguma adequada para programação. A pior parte é que os caras da Microsoft estão misturando APIs que podem levar um aplicativo totalmente compatível com caminho UNC de volta ao 260-MaxPath-StoneAge por causa de apenas uma chamada para uma API incompatível (cf. (2)). As Explorer e outros produtos ( incluindo cmd & powershell) da Microsoft pode nunca superar este problema devido à sua história (as votações sob os links para eliminar o limite são ignoradas ou recusadas).
Dependendo do caso de uso e da versão, o limite parece variar. O Windows 8 Explorer parece ser capaz de lidar com caminhos 4 vezes mais longos ( 4 ) enquanto do Windows 7 em diante o caminho de arquivo mais longo com permissão para ser movido para a Lixeira diminuiu de 259 para 215 ( 5 ). Por que os programadores começando do zero com o Windows NT não implementaram uma alocação dinâmica, ainda é um enigma. Uma abordagem para a situação atual usando a API não-Unicode é descrita aqui ( cópia ).
Outros tópicos relacionados à programação e caminhos UNC na rede SO:
6 caminhos UNC em Java e sua realização no nível da JVM.
Casos me deparei onde esse limite é realmente chato:
Organizando hierarquias de código-fonte: nodeJS
Fazendo backup de arquivos em estruturas de pastas profundas aninhadas
Convenção de nomenclatura para documentos (por exemplo, artigos com uma descrição longa - Resumo, Autores, Título, DOI - como nome para busca e localização rápidas)
Compartilhando arquivos entre o Linux (que não tem esse limite) e o Windows
Você pode querer tentar apropriar-se do arquivo e ver se é possível excluí-lo. Você pode fazer isso clicando com o botão direito do mouse no arquivo: Properties - > Segurança - > Avançado - > Proprietário - > Edite e altere o proprietário para seu nome de usuário (ou grupo Administradores).
Para mais informações, consulte este .
Isso é o que funcionou para mim em uma situação semelhante:
Primeiro, tentei assumir a responsabilidade:
takeown /r /d y /f my_folder
Isso não funcionou para alguns arquivos. Então eu usei cygwin que eu já tinha instalado e simples correu:
rm -rf path/to/my_folder
Voila, embora.