Některé složky a/nebo soubory na externím pevném disku jsou přístupné v systému Linux, ale ne v systémech macOS a Windows

Tuto odpověď zveřejňuji jen proto, abych řekl, jak byl problém vyřešen, čímž shrnuji komentáře k původní otázce, což by mohlo být užitečné pro ostatní.

Opravil jsem problém v Linuxu, kde byly tyto složky vytvořeny, jednoduše zkrácením názvu dvou nebo tří video souborů, které měly dlouhé názvy, ale žádné zjevně zvláštní znaky jako čárky, závorky atd. Změnil jsem také složku jména — ačkoliv neměla nic zvláštního. Jejich výměnou zpět se problém nereprodukoval.

Takže buď názvy složek měly nějaký špatný znak, který nebyl v Linuxu vidět, nebo špatné znaky v některých ze tří souborů, které byly přejmenovány, způsobily, že celá složka byla neviditelná na Macu a všech jeho obsahuje nehratelné ve Windows.

To je ta nejpodivnější věc, že ​​před přejmenováním složek a tří souborů žádné souborů bylo možné přehrát ve Windows.

Mohlo to být, jak řekl @Giacomo1968 v komentáři:

‘…znak „fantoma“ v původním názvu souboru... Něco jako návrat vozíku nebo nepřerušitelná mezera, která byla v Linuxu zpracována jedním způsobem, ale v jiných systémech byla dusena.‘

Jde o to, že před vyřešením problému jsem se pokusil ve Windows přehrát jiné soubory než ty, které byly nakonec přejmenovány. Fantomová postava mohla být také v názvech složek.

Stalo se mi to znovu na novém disku naformátovaném jako exFAT s jinými soubory ve složce, o které byla v Linuxu správcem souborů Nemo hlášena chyba při kopírování (něco jako "nelze vytvořit soubor"), ale pak ve skutečnosti vše vypadalo v pořádku Linux. Tato složka byla vidět, ale zůstala zcela nepřístupná ve Windows (nepamatuji si přesně chybovou zprávu , něco o tom, že soubor nebo složka neexistuje), a byla vidět na Macu, kromě jednoho jediného souboru, který zůstal neviditelný. Po přejmenování v Linuxu složku a soubor se stejným názvem vše proběhlo normálně!

Nyní mám podezření, že příčinou počátečního problému uvedeného v otázce a vytvoření špatné „fantomové“ postavy byla nějaká chyba během procesu kopírování nebo vložení názvu textu zkopírovaného z internetových stránek (kde to, co vypadá například jako prostor, je ve skutečnosti něco jiného). To mi napověděla skutečnost, že při kopírování pomocí Double Commander v Linuxu byly hlášeny podrobné chyby u některých názvů, včetně mezer, které mohly být znaky Tab nebo něco podobného.

Nakonec bylo nejlepším řešením pro kopírování použít Double Commander v Linuxu, který velmi jasně označoval název souboru, který měl problémy.

Kopírování/vkládání internetového textu při pojmenovávání souborů nebo složek musí být prováděno opatrně.

Způsob, jakým názvy souborů/složek fungují v systému Windows, je popsán na webu společnosti Microsoft. To však poskytuje pouze letmý pohled na celkovou pravdu.

Pozn.:nebudu diskutujte o aspektech problémů s kódovou stránkou, které mohou vzniknout ze způsobu, jakým „cizí“ systém přistupuje ke svazku NTFS. Myslím, že to je dostatečně pokryto v komentářích a další odpovědi. Omezím se převážně na následující dva aspekty:

• omezení délky názvu cesty
• kombinace znaků, ke kterým je obtížné/nemožné získat přístup ze subsystému Win32

Pokud jde o souborový systém, omezím se na NTFS, stejně jako otázka. Zvažte následující komentář z výše odkazovaného webu:

Neukončujte název souboru nebo adresáře mezerou nebo tečkou. Přestože základní souborový systém může takové názvy podporovat, prostředí Windows a uživatelské rozhraní ne .

Nyní si nejprve musíme ujasnit nějakou terminologii. Zabýváme se různými ... vrstvami, je asi vhodný termín:

• systém souborů, např. NTFS
• Správce objektů NT a další zařízení jádra, ale pokud jde o jména, většinou správce objektů
  (pokud se na to chcete podívat, použijte nástroj jako WinObj)
• Subsystém Win32 (to je to, co výše uvedené prohlášení označuje jako „prostředí a uživatelské rozhraní systému Windows“)
• Dalším „meta aspektem“ by byla verze operačního systému, protože podporovaná délka cesty se může lišit

Pěknou metodou, jak si s tím pohrát, je sdílení Samba, které na straně klienta předstírá, že je NTFS. Ale postačí i svazek Windows NTFS. Budeme ve Windows a „hrajeme si“ z příkazového řádku (stiskněte Win +R a zadejte cmd a poté stiskněte Enter ).

Místní svazek NTFS

Předpokládejme, že jsme chtěli vytvořit neplatný název souboru (všimněte si koncové tečky?!):

echo NONSENSE > text.txt.

Když se o to pokusíte, výsledek bude skutečně test.txt , ne test.txt. . Podsystém Win32 (csrss.exe) nám bránil dělat hlouposti. Hmm, zajímavé, co?

Zvažte toto další tvrzení:

Pro název souboru nepoužívejte následující vyhrazené názvy:

CON , PRN , AUX , NUL , COM1 , COM2 , COM3 , COM4 , COM5 , COM6 , COM7 , COM8 , COM9 , LPT1 , LPT2 , LPT3 , LPT4 , LPT5 , LPT6 , LPT7 , LPT8 a LPT9 . Vyhněte se také těmto názvům bezprostředně následovaným příponou; například NUL.txt se nedoporučuje.

Hmm, NUL Zní to jako legrace. Víme to z náhrady za /dev/null na unixoidních systémech, zděděných z dob DOS.

echo NONSENSE > NUL

Ajo. Je to náhrada za /dev/null , takže výstup bude spolknut. Ale nepoužívejte zní tak velmi lákavě. Použijme tedy shrnuté informace z článku na blogu Project Zero v sekci „Místní zařízení“.

Krátká přestávka:%CD%

Pokud nejste příliš obeznámeni s klasickým příkazovým řádkem Windows (cmd.exe ), speciální proměnná %CD% nám poskytne absolutní cestu k aktuálnímu pracovnímu adresáři. Mějte to na paměti pro následující sekci. Pokud jste tedy aktuálně byli uvnitř C:\test , příkaz echo %CD% výsledkem by byl C:\test . Je to pohodlná zkratka pro experimenty.

Jak můžeme zjistit z článku Project Zero, existuje řada způsobů, jak se vyhnout převodům názvů cest na úrovni subsystému Win32. Jednou z takových metod je předpona \\?\ které interně přímo překládá do \??\ , který je v novějších verzích Windows shodný s \GLOBAL??\ . Říká se tomu adresář objektů (nepleťte si to prosím s entitami systému souborů , navzdory podobné terminologii!). Opět platí, že WinObj a podobné nástroje vám umožní prozkoumat jmenný prostor správce objektů.

Interlude:jmenné prostory a "věci" terminálového serveru

Kdo nahlédl do historie Windows NT a Windows 10 vystopoval své kořeny až k NT, pamatuje si dobu, kdy bylo nutné samostatně licencovat terminálové služby. Tj. možnost vzdáleného připojení k jedinému počítači s různými uživateli.

Myslím, že to byl Windows XP, který to konečně přinesl pro masy tím, že umožnil zůstat přihlášeni s více uživatelskými účty současně („přepínání uživatelů“) a pravděpodobně Windows 2000 nebo 2003 Server to zahrnuly do standardní edice, i když licence CAL byly potřeba nad rámec minimálních „míst“ zahrnutých ve výchozím nastavení.

Zde je rozdíl mezi \?? a \GLOBAL?? pochází. \GLOBAL?? je zobrazení názvů zařízení "DOS" sdílených všemi přihlašovací relace.

\?? je dnes vidět v symbolickém odkazu (opět není entita souborového systému! ) s názvem \DosDevices , který napovídá o jeho původu. Zde jsou názvy zařízení "DOS", například C: nebo se nachází mapování síťové jednotky. Na moderním systému C: zase by to byl symbolický odkaz na \Device\HarddiskVolume1 (nebo podobné). To je pak obvykle skutečný objekt zařízení, který byl vytvořen nějakým ovladačem v zásobníku ovladačů úložiště, v tomto případě měl by být ovladačem systému souborů NTFS.

Když tedy dvakrát kliknete na C:\Windows\explorer.exe interně se stane, že se cesta převede:

• Na úrovni subsystému Win32 bude obvyklou změnou přidání \??\ .
• Správce objektů poté rozbalí \??\C: .
  • První \??\ skončí ve jmenném prostoru zařízení "DOS" pro vaši přihlašovací relaci (viz poznámka níže)
  • Správce objektů nakonec zjistí něco jako \??\C: je ekvivalentní \GLOBAL??\C: což - jak jsme viděli výše - je ekvivalentní \Device\HarddiskVolume1 .

Správce objektů pak předá zbytek cesty \Windows\explorer.exe na ovladač zodpovědný za objekt zařízení \Device\HarddiskVolume1 , ujistěte se, že ovladač ví, na který objekt zařízení bylo odkazováno. A tento ovladač bude vědět, jak ve svém vlastním jmenném prostoru zpracovat tento konkrétní zbytek cesty.

Poznámka: Když odkazujete na \?? interně skončíte s pohledem na „DOS“ zařízení vaší místní přihlašovací relace. To lze nejlépe vysvětlit namapovanými síťovými disky. Řekněme, že máte písmeno jednotky X: mapováno pro vzdálenou sdílenou položku. A řekněme, že používáte "přepínání uživatelů" nebo to běží na robustním terminálovém serveru, kde je současně přihlášeno dalších dvě stě uživatelů. V takovém scénáři máme dva problémy. Zatímco systémový disk (např. fyzický disk) mohou sdílet všichni, někdo z prodejců mohl namapovat „the podíl prodeje" jako X: a někdo z vývoje možná zmapoval "the vývojový podíl". Totéž platí pro „písmeno jednotky" přiřazené přes subst . To by mělo vysvětlovat, proč nemůže existovat jeden globální jmenný prostor pro názvy zařízení „DOS“, který by vyhovoval všem.

Naším cílem tedy bylo vytvořit soubor (nebo adresář) s názvem NUL a subsystém Win32 nám to nedovolil. Jednoduše to spolklo výstup a soubor nebyl nikdy vytvořen v našem pracovním adresáři. Využitím informací z výše propojeného článku a předchozí mezihry to však můžeme obejít tím, že se vyhneme těm otravným převodům cest na úrovni subsystému vydáním:

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

Připomínáme, %CD% expanduje na absolutní cestu aktuálního pracovního adresáře a za předpokladu, že je to C:\test , výše uvedený příkaz je ekvivalentní echo NONSENSE > \\?\C:\test\NUL .

A ejhle, rychlý dir dokazuje, že soubor byl vytvořen. A pokud to zkusíme s jinými "rezervovanými" jmény, funguje to také dobře.

Upozorňujeme, že můžete použít také skutečné nativní formulář cesty NT (\?? místo \\? ) pro stejný efekt:

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

Pěkné.

Co kdybychom se znovu podívali na pokus o koncovou tečku, ale uvedli úplnou cestu, aniž by do toho zasahoval subsystém Win32?:

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

Voila, funguje to jako rychlý dir /b dokazuje:

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

Interlude:Cesty UNC (Universal Naming Convention)

Toto téma je podrobněji zpracováno v článku Project Zero, ale stačí říci, že existuje speciální forma cesty, která vypadá docela podobně jako ta, kterou jsme právě použili výše:\\.\C:\Windows\explorer.exe by byl příkladem.

Pamatujete si, že kdykoli se zaseknete na přihlašovací obrazovce, nepamatujete si název místního počítače a výchozím nastavením je doména, jejímž je členem? Jeden snadný způsob, jak odkazovat na aktuální počítač aniž by bylo použito jeho skutečné jméno je .\username , což umožňuje odkazovat na uživatele username na aktuálním počítači .

. v \\.\C:\Windows\explorer.exe je třeba chápat podobně. Ve skutečnosti to, co říkáte, je \\. na aktuálním počítači \C: na disku C: přístupová cesta \Windows\explorer.exe ...a různá zařízení OS se vzájemně propojují, aby se to stalo.

Pozor :Cesty UNC se řídí jinou sadou pravidel, proto je uvádím pouze. Pokud vás zajímají další podrobnosti, přečtěte si odkazovaný článek a odkaz na dokumentaci společnosti Microsoft.

Nyní, když jsme konečně vytvořili "nemožný" soubor test.txt. , pojďme se na to podívat, ano?

C:\test>type test.txt
NONSENSE

Co to sakra? Jasně si vzpomínám, že jsem opakoval ILLEGAL TRAILING DOT do tohoto souboru.

Aha, samozřejmě. Stejně jako když jsme původně zkoušeli vytvořit test.txt. subsystém Win32 opět zasáhl a "pomocně" převedl naše jméno na test.txt . Takže se vlastně díváme na \??\%CD%\test.txt místo \??\%CD%\test.txt. .

Takže by to mělo fungovat:

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

Mnohem lepší. Problém je v tom, že ne všechny programy zvládnou naše záludné obcházení převodů názvů cest Win32 tak elegantně jako cmd.exe . Předpokládejme, že jsme chtěli otevřít Poznámkový blok:

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

Sakra, vidíme následující okno se zprávou:

Takže i když existují způsoby, jak některé obejít z omezení uložených subsystémem Win32 je užitečnost těchto metod omezená a sporná.

Poznámka :Čtenáři, kteří se také rozvíjejí software na/pro Windows si může vzpomenout na použití předpony \\?\ povoleno obejít MAX_PATH limit (dříve 260, v podstatě 255 plus \\?\ a ukončovací \0 ). Nyní víte, proč nám to umožňuje využívat přibližně 32767 znaků. Protože UCS-2 byl nahrazen UTF-16 (myslím, že v XP), je mandlování cesty na úrovni správce objektů jen jedním problémem. Další je, že v UTF-16 může bod kódu zabírat více než 16 bitů (aka wchar_t nebo WCHAR ), jakmile opustíte BMP.

Každopádně příkazový řádek (cmd.exe ) vám poskytuje všechny nástroje pro přístup k souborům, které jste mohli vytvořit v systému Windows, a zbavit se jich.

Linux/Samba sdílení, vydávající se za NTFS

Přejděme nyní od místního disku a uvažujme namapovaný síťový disk Z: , kterou poskytuje Samba 4.x, která napodobuje disk NTFS, pokud jde o Windows.

Tento experiment nabízí několik dalších poznatků, protože můžeme vytvářet soubory podle pravidel na straně Linuxu a nemusíme se obávat, že k nim nebudeme moci přistupovat ze strany Windows.

• Namapovaná jednotka je Z: a budeme v Z:\test na straně Windows
• Na straně Linuxu byl svazek naformátován jako btrfs
  Článek Wikipedie nám říká všechny znaky jiné než / a \0 (aka ASCII NUL znak) jsou povoleny! Tak tohle by měla být zábava.

Zde je několik extravagantních názvů souborů, které by měly (nebo alespoň mohly) být obtížně přístupné na straně Windows, k jejich vytvoření použijte Bash na Ubuntu 20.04 na straně Linuxu:

• :.txt (vytvořeno pomocí echo "$RANDOM" > \:.txt )
• ???.txt (vytvořeno pomocí echo "$RANDOM" > \?\?\?.txt )
• .txt (vytvořeno pomocí echo "$RANDOM" > .txt )
• *.txt (vytvořeno pomocí echo "$RANDOM" > \*.txt )
• \.txt (vytvořeno pomocí echo "$RANDOM" > \\.txt )
• ".txt (vytvořeno pomocí echo "$RANDOM" > \".txt )
• >.txt (vytvořeno pomocí echo "$RANDOM" > \>.txt )
• <.txt (vytvořeno pomocí echo "$RANDOM" > \<.txt )
• |.txt (vytvořeno pomocí echo "$RANDOM" > \|.txt )

To by mělo v podstatě pokrýt všechny základy, ve skutečnosti nemusí být emotikony vůbec problém. Lomítka jsou také zakázána na NTFS, ale to platí i pro btrfs/POSIX/SUS.

Důkaz ze strany Linuxu:

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

Nyní se podívejme, zda a k čemu máme přístup na straně Windows ...

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

Snímek obrazovky jako důkaz:

Ohhhhh! Správně, dědictví DOS Windows znovu udeří. NTFS – pokud jej aktivně nedeaktivujete – má schopnost vytvářet takzvané krátké názvy souborů 8.3, které odpovídají požadavkům na názvy souborů DOS.

A tak jsme schopni přistupovat k neplatným názvům souborů bez ohledu na to.

Závěr

Nyní si vzpomeňte, otázka se týkala externího, tedy místního disku NTFS. To znamená, že pravidla, která jsme právě dodrželi pro sdílení Samba, zde nemusí platit.

V závislosti na ovladači použitém k ukládání těchto souborů (který se může lišit podle verze Linuxu/macOS, např. ntfs-3g nebo použitého ovladače třetí strany, např. Paragon's driver) vidím po zhlédnutí výše uvedených experimentů následující možné příčiny:

1. název souboru obsahoval : , " nebo ? ... to se mi zdá nejpravděpodobnější, vzhledem k tomu, že jsem sám omylem zkopíroval a vložil názvy e-knih obsahující tyto znaky. Můžeme do značné míry vyloučit / a další „zakázané“ postavy jsou přinejmenším méně pravděpodobné.
2. strana Windows a macOS vidí neplatný název, zkuste se podívat na název DOS 8.3, ale žádný nebyl vygenerován. To poněkud závisí na přesné verzi Windows a její konfiguraci, a protože v okolí nemám žádná zařízení macOS, nemohu ani tento scénář otestovat. Také si nejsem jistý, zda v systému Windows, kde jsou povoleny názvy 8.3 Windows by zpětně vygeneroval název 8.3, pokud by, řekněme, linuxová strana tuto část přeskočila. Protože pokud si dobře vzpomínám, ovladač NTFS rozhoduje, zda se příslušný záznam ("atribut") vyplní.
3. délka názvu cesty byla překročena. Myslím si, že překročení délky segmentů cesty je nemožné, protože NTFS vám neumožňuje uložit více než 255 16bitových hodnot pro segment cesty, ale také mohla být překročena celková délka cesty (viz tento odkaz).

Pro první scénář bych doporučil použít fslint na straně Linuxu k dezinfekci názvů souborů (a složek). Existují další podobné nástroje a YMMV, vyberte si.

Snad to pomůže. Trvalo dost dlouho, než jsem své myšlenky vložil do psaní.

Další čtení

• Pojmenování souborů, cest a jmenných prostorů
• Definitivní průvodce převodem cesty z Win32 na NT