Algumas pastas e/ou arquivos em HDD externo são acessíveis no Linux, mas não no macOS e Windows

Estou postando esta resposta apenas para dizer como o problema foi resolvido, resumindo assim os comentários feitos à pergunta original , que podem ser úteis para outras pessoas.

Corrigi o problema no Linux, onde essas pastas foram criadas, simplesmente encurtando o título de dois ou três dos arquivos de vídeo, que tinham nomes longos, mas sem caracteres obviamente estranhos, como vírgulas, colchetes, etc. nomes - embora não tivessem nada de especial. Mudá-los de volta não reproduziu o problema.

Portanto, ou os nomes das pastas tinham algum caractere errado que não era visível como tal no Linux, ou os caracteres ruins em alguns dos três arquivos que foram renomeados tornaram a pasta inteira invisível no Mac e todos os seus conteúdos não podem ser reproduzidos no Windows.

Esta é a coisa mais estranha que, antes de renomear as pastas e os três arquivos, nenhum dos arquivos era reproduzível no Windows.

Pode ter sido, como @Giacomo1968 disse em um comentário :

'...um caractere 'fantasma' no nome do arquivo original... Algo como um retorno de carro ou espaço ininterrupto que foi tratado de uma maneira no Linux, mas bloqueado em outros sistemas.'

O problema é que antes de corrigir o problema tentei reproduzir no Windows outros arquivos além daqueles que foram renomeados no final. O caractere fantasma também pode estar nos nomes das pastas.

Aconteceu comigo novamente em uma nova unidade formatada como exFAT com outros arquivos em uma pasta sobre a qual um erro foi relatado no Linux pelo gerenciador de arquivos Nemo durante a cópia (algo como "não é possível criar arquivo"), mas na verdade tudo parecia bem no Linux. Essa pasta foi vista, mas permaneceu completamente inacessível no Windows (não me lembro exatamente da mensagem de erro, algo sobre arquivo ou pasta não existente), e foi vista em um Mac, exceto um único arquivo, que permaneceu invisível. Após renomear no Linux a pasta e o arquivo com o mesmo nome tudo correu normalmente!

Agora suspeito que a causa do problema inicial relatado na pergunta e a criação de um caractere 'fantasma' ruim foi algum erro durante um processo de cópia ou a colagem no título do texto copiado de páginas da Internet (onde o que parece um espaço, por exemplo, é de fato outra coisa). Isso foi sugerido para mim pelo fato de que, ao copiar com o Double Commander no Linux, ele relatou erros detalhados em alguns nomes que incluem espaços que podem ser caracteres Tab ou algo semelhante.

(Para evitar esses erros ao copiar/colar o texto selecionado da Internet, algo como um complemento "copiar somente texto" para o firefox pode ser muito útil.)

No final, a melhor solução para copiar foi usar o Double Commander no Linux que indicava muito claramente o nome do arquivo que apresentava problemas.

Copiar/colar texto da Internet ao nomear arquivos ou pastas deve ser feito com cuidado.

A maneira como os nomes de arquivos/pastas funcionam no Windows é discutida no site da Microsoft . No entanto, isso fornece apenas um vislumbre da verdade geral.

NB: não discutirei o aspecto dos problemas de página de código que podem surgir da maneira como um sistema "estrangeiro" acessa um volume NTFS. Acho que isso está suficientemente coberto nos comentários e na outra resposta. Limitar-me-ei largamente aos dois aspectos seguintes:

• limitações de comprimento do nome do caminho
• combinações de caracteres que são difíceis/impossíveis de acessar do subsistema Win32

Quanto ao sistema de arquivos, vou me limitar ao NTFS, assim como a pergunta. Considere o seguinte comentário do site vinculado acima:

Não termine um nome de arquivo ou diretório com um espaço ou um ponto. Embora o sistema de arquivos subjacente possa oferecer suporte a esses nomes, o shell do Windows e a interface do usuário não .

Agora, precisamos entender um pouco da terminologia primeiro. Lidamos com várias ... camadas, provavelmente é um termo adequado:

• sistema de arquivos, por exemplo, NTFS
• Gerenciador de objetos NT e outras facilidades do kernel, mas quando se trata de nomes principalmente o gerenciador de objetos
  (se você quiser dar uma olhada, use uma ferramenta como WinObj )
• Subsistema Win32 (isto é o que a declaração acima se refere como "shell do Windows e interface do usuário")
• Outro "meta aspecto" seria a versão do sistema operacional, porque o comprimento do caminho suportado pode variar

Um bom método para brincar com isso é um compartilhamento Samba que finge ser NTFS para o lado do cliente. Mas um volume Windows NTFS também serve. Estaremos no Windows e "brincar" a partir da linha de comando (pressione Win+ Re digite cmd, depois pressione Enter).

Volume NTFS local

Suponha que queiramos criar um nome de arquivo inválido (observe o ponto final?!):

echo NONSENSE > text.txt.

Ao tentar isso, o resultado será de fato test.txt, não test.txt. . O subsistema Win32 (csrss.exe) nos impediu de fazer coisas estúpidas. Hum, interessante, hein?

Considere esta outra afirmação:

Não use os seguintes nomes reservados para o nome de um arquivo:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, e . LPT7_ Evite também esses nomes seguidos imediatamente por uma extensão; por exemplo, não é recomendado.LPT8LPT9NUL.txt

Hmm, NULparece divertido. Sabemos disso por ser um substituto para /dev/nullsistemas unixoid, herdados dos tempos do DOS.

echo NONSENSE > NUL

Oh, certo. É um substituto para /dev/null, então a saída será engolida. Mas não use sons tão tentadores. Então, vamos usar as informações resumidas de um artigo do blog do Project Zero , seção "Dispositivo Local".

Breve interlúdio:%CD%

Se você não estiver muito familiarizado com a linha de comando clássica do Windows ( cmd.exe), a variável especial %CD%nos dará o caminho absoluto para o diretório de trabalho atual. Tenha isso em mente para a seção a seguir. Portanto, se você estivesse atualmente dentro C:\test, o comando echo %CD%produziria a saída C:\test. É um atalho conveniente para nossos experimentos.

Como podemos ver no artigo do Project Zero, há várias maneiras de evitar conversões de nome de caminho no nível do subsistema Win32. Um desses métodos é o prefixo que se traduz \\?\internamente diretamente\??\ em , que nas versões mais recentes do Windows é idêntico a \GLOBAL??\. Isso é chamado de diretório de objeto (por favor, não o confunda com entidades do sistema de arquivos , apesar da terminologia semelhante!). Novamente, WinObj e ferramentas semelhantes permitem que você investigue o espaço de nomes do gerenciador de objetos.

Interlude: namespaces e "coisas" do servidor de terminal

Quem já deu uma olhada na história do Windows NT, e o Windows 10 rastreia suas raízes até o NT, vai se lembrar de uma época em que você tinha que licenciar separadamente os serviços de terminal. Ou seja, a capacidade de se conectar a uma única máquina remotamente com diferentes usuários.

Eu acho que foi o Windows XP que finalmente trouxe isso para as massas, permitindo permanecer conectado com várias contas de usuário simultaneamente ("troca de usuário"), e provavelmente o Windows 2000 ou 2003 Server incluiu isso na edição padrão, embora as CALs eram necessários além dos "lugares" mínimos incluídos por padrão.

É aqui que se origina a distinção entre \??e . é a exibição dos nomes de dispositivos "DOS" compartilhados por todas as sessões de logon.\GLOBAL??\GLOBAL??

\??é hoje visto no link simbólico (novamente, não uma entidade do sistema de arquivos! ) chamado \DosDevices, que dá uma pista sobre sua origem. É aqui que residem os nomes de dispositivos "DOS", como C:mapeamentos de unidades de rede. Em um sistema moderno, C:por sua vez, seria um link simbólico para \Device\HarddiskVolume1(ou similar). Isso geralmente é um objeto de dispositivo real que foi criado por algum driver na pilha do driver de armazenamento; nesse caso, deve ser o driver do sistema de arquivos NTFS.

Então quando você clica duas vezes C:\Windows\explorer.exeo que acontece internamente é que o caminho é convertido:

• No nível do subsistema Win32, a alteração usual será prefixar \??\.
• O gerenciador de objetos expandirá o arquivo \??\C:.
  • O primeiro \??\termina no namespace do dispositivo "DOS" para sua sessão de logon (veja a observação abaixo)
  • Eventualmente, o gerenciador de objetos descobre algo como \??\C:ser equivalente a \GLOBAL??\C:que - como vimos acima - é equivalente a \Device\HarddiskVolume1.

O gerenciador de objetos então passará o restante do caminho \Windows\explorer.exepara o driver responsável pelo device object \Device\HarddiskVolume1, certificando-se de que o driver saiba qual objeto de dispositivo foi referenciado. E esse driver saberá como, dentro de seu próprio namespace, lidar com esse restante específico do caminho.

Observação: Quando você faz referência a \??internamente, acaba tendo uma visão dos dispositivos "DOS" da sessão de logon local. Isso pode ser melhor explicado com unidades de rede mapeadas. Digamos que você tenha uma letra de unidade X:mapeada para um compartilhamento remoto. E digamos que você faz uso de "troca de usuário" ou isso está sendo executado em um servidor de terminal robusto, onde outros duzentos usuários estão conectados simultaneamente. Temos dois problemas em mãos em tal cenário. Enquanto a unidade do sistema (por exemplo, disco físico) pode ser compartilhada por todos, alguém de vendas pode ter mapeado " a participação de vendas" X:e alguém do desenvolvimento pode ter mapeado " a participação de desenvolvimento". O mesmo vale para uma "letra de unidade" atribuída viasubst. Isso deve explicar por que não pode haver um único namespace global para nomes de dispositivos "DOS", que se adapte a todos.

Então nosso objetivo era criar um arquivo (ou diretório) nomeado NULe o subsistema Win32 não nos permitiu. Ele simplesmente engoliu a saída e o arquivo nunca foi criado em nosso diretório de trabalho. Aproveitando as informações do artigo vinculado acima e do interlúdio anterior, no entanto, podemos contornar isso evitando essas conversões de caminho traquinas no nível do subsistema emitindo um:

echo NONSENSE > \\?\%CD%\NUL

Como lembrete, %CD%expande para o caminho absoluto do diretório de trabalho atual e, supondo que seja C:\test, o comando acima é equivalente a echo NONSENSE > \\?\C:\test\NUL.

E eis que, uma rápida dirprova que o arquivo foi criado. E se tentarmos isso com outros nomes "reservados", também funcionará bem.

Observe que você também pode usar o formulário de caminho do NT nativo real\?? ( em vez de \\?) para o mesmo efeito:

echo NONSENSE > \??\%CD%\NUL

Organizado.

Então, que tal revisitarmos a tentativa do ponto final, mas dando o caminho completo sem que o subsistema Win32 interfira?:

echo ILLEGAL TRAILING DOT > \??\%CD%\test.txt.

dir /bVoila, funciona, como prova rápida :

C:\test>dir /b
CON
NUL
test.txt
test.txt.

Interlúdio: caminhos UNC (Convenção Universal de Nomenclatura)

Este tópico é tratado com mais detalhes naquele artigo do Project Zero, mas basta dizer que existe uma forma especial de caminho que se parece bastante com o que acabamos de usar: \\.\C:\Windows\explorer.exeseria um exemplo.

Lembra que sempre que você fica travado na tela de logon, não lembrando o nome da máquina local da máquina, e o padrão é o domínio do qual ela é membro? Uma maneira fácil de fazer referência à máquina atual sem usar seu nome real é .\usernamepermitir fazer referência ao usuário usernamena máquina atual .

O .in \\.\C:\Windows\explorer.exedeve ser entendido da mesma forma. Na verdade, o que você está dizendo está \\. na máquina atual \C: noC: caminho de acesso da unidade \Windows\explorer.exe... e as diferentes instalações do sistema operacional se conectam para que isso aconteça.

Cuidado : os caminhos UNC seguem um conjunto diferente de regras, e é por isso que apenas os mencionei. Leia o artigo vinculado e o link para a documentação da Microsoft se estiver interessado em mais detalhes.

Agora que finalmente criamos um arquivo "impossível" test.txt., vamos dar uma olhada nele, certo?

C:\test>type test.txt
NONSENSE

Que diabos? Lembro-me claramente de ter ecoado ILLEGAL TRAILING DOTnesse arquivo.

Ah, claro. Assim como quando inicialmente tentamos criar test.txt.o subsistema Win32, intervimos novamente e "utilmente" converteu nosso nome para test.txt. Então, na verdade, estamos olhando em \??\%CD%\test.txtvez de \??\%CD%\test.txt..

Então isso deve fazer:

C:\test>type \??\%CD%\test.txt.
ILLEGAL TRAILING DOT

Muito melhor. O problema é que nem todos os programas lidarão com nosso desvio sorrateiro das conversões de nome de caminho do Win32 com a mesma facilidade do cmd.exe. Suponha que queiramos abrir o Bloco de Notas:

C:\test>notepad \??\%CD%\test.txt.

Dang, podemos ver a seguinte caixa de mensagem:

Portanto, embora existam maneiras de contornar algumas das restrições impostas pelo subsistema Win32, a utilidade desses métodos é limitada e questionável.

Nota : Os leitores que também desenvolvem software no/para Windows devem lembrar que usar o prefixo \\?\permitia contornar o MAX_PATHlimite (costumava ser 260, basicamente 255 mais \\?\e um terminando \0). Agora você sabe por que isso nos permite usar aproximadamente 32.767 caracteres . Como o UCS-2 foi substituído pelo UTF-16 (acho que no XP), o desmembramento do caminho no nível do gerenciador de objetos é apenas um problema. Outra é que em UTF-16 um ponto de código pode ocupar mais de 16 bits (aka wchar_tou WCHAR), uma vez que você deixa o BMP para trás.

De qualquer forma, a linha de comando ( cmd.exe) fornece todas as ferramentas para acessar e se livrar dos arquivos que você conseguiu criar no Windows em primeiro lugar.

Compartilhamento Linux/Samba, fingindo ser NTFS

Vamos agora partir da unidade local e considerar uma unidade de rede mapeada Z:, fornecida pelo Samba 4.x, que imita uma unidade NTFS no que diz respeito ao Windows.

Este experimento oferece mais alguns insights, porque podemos criar arquivos de acordo com as regras do lado do Linux e não precisamos ficar ansiosos por não conseguir acessá-los do lado do Windows.

• A unidade mapeada é Z:e estaremos no Z:\testlado do Windows
• No lado do Linux, o volume foi formatado como btrfs
  O artigo da Wikipedia nos diz que todos os caracteres exceto /e \0(também conhecido como caractere ASCII NUL ) são permitidos! Então isso deve ser divertido.

Here are some extravagant file names which should (or at least could) be hard to access on the Windows side, using Bash on Ubuntu 20.04 on the Linux side to create them:

• :.txt (created with echo "$RANDOM" > \:.txt)
• ???.txt (created with echo "$RANDOM" > \?\?\?.txt)
• ?.txt (created with echo "$RANDOM" > ?.txt)
• *.txt (created with echo "$RANDOM" > \*.txt)
• \.txt (created with echo "$RANDOM" > \\.txt)
• ".txt (created with echo "$RANDOM" > \".txt)
• >.txt (created with echo "$RANDOM" > \>.txt)
• <.txt (created with echo "$RANDOM" > \<.txt)
• |.txt (created with echo "$RANDOM" > \|.txt)

This should pretty much cover all bases, actually on second thought the emoji may not even be an issue at all. Forward slashes are also forbidden on NTFS, but that holds true for btrfs/POSIX/SUS as well.

Proof from the Linux side:

$ find -type f -printf '%P\n'
:.txt
???.txt
?.txt
*.txt
\.txt
".txt
>.txt
<.txt
|.txt

Now let's see if and what we can access on the Windows side ...

Z:\test>dir /b
_2X68P~X.TXT
_2X68Q~5.TXT
_2X68Q~9.TXT
_2X68Q~B.TXT
_2X68Q~D.TXT
_2X68R~7.TXT
_2X68S~3.TXT
_67V3K~2.TXT
?.txt

Screenshot as proof:

Ohhhhh! Right, the DOS heritage of Windows strikes again. NTFS - unless actively disabling it - has the ability to create so-called 8.3 short file names, conforming to the DOS file name requirements.

And that's how we are able to access the invalid file names regardless.

Conclusion

Now recall, the question was about an external, i.e. local, NTFS drive. This means the rules we just observed for Samba shares may not apply here.

Depending on the driver used to store these files (which could vary by Linux/macOS version, e.g. ntfs-3g or the third-party driver used, e.g. Paragon's driver) I see the following possible causes left after looking at the above experiments:

1. the file name contained a :, " or ? ... this seems the most likely to me, given I'd had accidentally copied and pasted ebook titles myself, containing these characters. We can pretty much rule out / and the other "forbidden" characters are at least less likely.
2. the Windows and macOS side see the invalid name, attempt to look at the DOS 8.3 name, but none was generated. This somewhat depends on the exact Windows version and its configuration and since I have no macOS devices around, I cannot test that scenario either. Also, I am not sure whether on a Windows system where 8.3 names are enabled Windows would retroactively go and generate a 8.3 name if, say, the Linux side skipped that part. Because if I recall correctly the NTFS driver decides whether the respective record ("attribute") gets populated.
3. o comprimento do nome do caminho foi excedido. Acho que exceder o comprimento dos segmentos de caminho é uma impossibilidade, porque o NTFS não permite armazenar mais de 255 valores de 16 bits para um segmento de caminho, mas o comprimento geral do caminho também pode ter sido excedido (consulte este link ).

Para o primeiro cenário, eu recomendaria usar fslint no lado do Linux para limpar os nomes dos arquivos (e pastas). Existem outras ferramentas semelhantes e YMMV, escolha.

Espero que isto ajude. Demorou o suficiente para despejar meus pensamentos na escrita.

Leitura adicional

• Nomeando arquivos, caminhos e namespaces
• O guia definitivo sobre conversão de caminho de Win32 para NT