Ich poste diese Antwort nur, um zu sagen, wie das Problem gelöst wurde, und fasse damit die Kommentare zusammen, die zur ursprünglichen Frage gemacht wurden und für andere nützlich sein könnten.
Ich habe das Problem in Linux behoben, wo diese Ordner erstellt wurden, indem ich einfach den Titel von zwei oder drei der Videodateien verkürzte, die lange Namen, aber keine offensichtlich ungeraden Zeichen wie Kommas, Klammern usw. hatten. Ich habe auch den Ordner geändert Namen – obwohl sie nichts Besonderes hatten. Das Zurücksetzen hat das Problem nicht reproduziert.
Also hatten die Ordnernamen entweder falsche Zeichen, die als solche unter Linux nicht sichtbar waren, oder die falschen Zeichen in einigen der drei Dateien, die umbenannt wurden, machten den gesamten Ordner auf dem Mac unsichtbar und alle es enthält unter Windows nicht spielbar.
Das ist das Seltsamste, dass vor dem Umbenennen der Ordner und der drei Dateien keine der Dateien waren unter Windows abspielbar.
Es könnte gewesen sein, wie @Giacomo1968 in einem Kommentar sagte:
„… ein „Phantom“-Zeichen im ursprünglichen Dateinamen … So etwas wie ein Wagenrücklauf oder ein geschütztes Leerzeichen, das unter Linux auf eine Weise behandelt wurde, aber auf anderen Systemen verschluckt wurde.“
Die Sache ist, dass ich vor der Behebung des Problems versucht habe, andere Dateien als die, die am Ende umbenannt wurden, in Windows abzuspielen. Das Phantomzeichen könnte auch in den Ordnernamen gewesen sein.
Es passierte mir wieder auf einem neuen, als exFAT formatierten Laufwerk mit anderen Dateien in einem Ordner, über den in Linux vom Nemo-Dateimanager beim Kopieren ein Fehler gemeldet wurde (so etwas wie "Datei kann nicht erstellt werden"), aber dann sah tatsächlich alles gut aus auf Linux. Dieser Ordner wurde gesehen, blieb aber in Windows völlig unzugänglich (ich erinnere mich nicht genau an die Fehlermeldung, etwas über Datei oder Ordner nicht vorhanden), und er wurde auf einem Mac gesehen, mit Ausnahme einer einzelnen Datei, die unsichtbar blieb. Nach dem Umbenennen in Linux den Ordner und die Datei mit demselben Namen alles lief normal!
Ich vermute jetzt, dass die Ursache für das in der Frage gemeldete anfängliche Problem und die Erstellung eines schlechten "Phantom" -Zeichens ein Fehler während eines Kopiervorgangs war oder das Einfügen von Titeln in von Internetseiten kopierte Texte (wobei das, was zum Beispiel wie ein Leerzeichen aussieht, tatsächlich etwas anderes ist). Dies wurde mir durch die Tatsache nahegelegt, dass beim Kopieren mit Double Commander unter Linux detaillierte Fehler bei einigen Namen gemeldet wurden, die Leerzeichen enthalten, die möglicherweise Tabulatorzeichen oder ähnliches waren.
Am Ende war die beste Lösung zum Kopieren die Verwendung von Double Commander unter Linux, der den Dateinamen, der Probleme hatte, sehr deutlich anzeigte.
Das Kopieren/Einfügen von Internettext beim Benennen von Dateien oder Ordnern muss mit Vorsicht erfolgen.
Die Funktionsweise von Datei-/Ordnernamen unter Windows wird auf der Microsoft-Website erläutert. Dies gibt jedoch nur einen kleinen Einblick in die allgemeine Wahrheit.
NB:Das werde ich nicht Erörtern Sie den Aspekt von Codepage-Problemen, die sich aus der Art und Weise ergeben können, wie ein "fremdes" System auf ein NTFS-Volume zugreift. Ich denke, dies ist in Kommentaren und der anderen Antwort ausreichend behandelt. Ich werde mich weitgehend auf die folgenden zwei Aspekte beschränken:
- Längenbeschränkungen für Pfadnamen
- Zeichenkombinationen, auf die vom Win32-Subsystem schwer/unmöglich zugegriffen werden kann
Beim Dateisystem beschränke ich mich wie bei der Frage auf NTFS. Betrachten Sie den folgenden Kommentar von der oben verlinkten Website:
Beenden Sie einen Datei- oder Verzeichnisnamen nicht mit einem Leerzeichen oder einem Punkt. Obwohl das zugrunde liegende Dateisystem solche Namen unterstützen kann, tun dies die Windows-Shell und die Benutzeroberfläche nicht .
Jetzt müssen wir zuerst einige der Terminologie klarstellen. Wir beschäftigen uns mit verschiedenen ... Schichten, ist wohl ein passender Begriff:
- Dateisystem, z.B. NTFS
- NT-Objektmanager und andere Kernel-Einrichtungen, aber wenn es um Namen geht meistens der Objektmanager
(wenn Sie es sich ansehen möchten, verwenden Sie ein Tool wie WinObj) - Win32-Subsystem (dies wird in der obigen Aussage als „Windows-Shell und -Benutzeroberfläche“ bezeichnet)
- Ein weiterer „Meta-Aspekt“ wäre die OS-Version, da die unterstützte Pfadlänge variieren kann
Eine nette Methode, um damit herumzuspielen, ist eine Samba-Freigabe, die auf der Client-Seite vorgibt, NTFS zu sein. Aber ein Windows NTFS-Volume reicht auch aus. Wir werden auf Windows sein und von der Befehlszeile aus "herumspielen" (drücken Sie Win +R und geben Sie cmd ein , dann Enter drücken ).
Lokales NTFS-Volume
Angenommen, wir wollten einen ungültigen Dateinamen erstellen (beachten Sie den nachgestellten Punkt?!):
echo NONSENSE > text.txt.
Wenn Sie dies versuchen, wird das Ergebnis tatsächlich test.txt sein , nicht test.txt. . Das Win32-Subsystem (csrss.exe) hat uns daran gehindert, Dummheiten zu machen. Hmm, interessant, oder?
Betrachten Sie diese andere Aussage:
Verwenden Sie nicht die folgenden reservierten Namen für den Namen einer Datei:
CON , PRN , AUX , NUL , COM1 , COM2 , COM3 , COM4 , COM5 , COM6 , COM7 , COM8 , COM9 , LPT1 , LPT2 , LPT3 , LPT4 , LPT5 , LPT6 , LPT7 , LPT8 , und LPT9 . Vermeiden Sie auch diese Namen, denen unmittelbar eine Erweiterung folgt; zum Beispiel NUL.txt wird nicht empfohlen.
Hm, NUL hört sich nach Spaß an. Wir kennen das vom Ersatz für /dev/null auf Unixoid-Systemen, geerbt aus DOS-Zeiten.
echo NONSENSE > NUL
Oh, richtig. Es ist ein Ersatz für /dev/null , sodass die Ausgabe verschluckt wird. Aber nicht verwenden hört sich sehr verlockend an. Verwenden wir also die zusammengefassten Informationen aus einem Project Zero-Blogartikel, Abschnitt „Lokales Gerät“.
Kurzes Zwischenspiel:%CD%
Wenn Sie mit der klassischen Windows-Befehlszeile (cmd.exe ), die spezielle Variable %CD% gibt uns den absoluten Pfad zum aktuellen Arbeitsverzeichnis. Behalten Sie dies für den folgenden Abschnitt im Hinterkopf. Wenn Sie also gerade in C:\test waren , der Befehl echo %CD% würde die Ausgabe C:\test ergeben . Es ist eine praktische Abkürzung für unsere Experimente.
Wie wir dem Project Zero-Artikel entnehmen können, gibt es eine Reihe von Möglichkeiten, Pfadnamenkonvertierungen auf der Ebene des Win32-Subsystems zu umgehen. Eine solche Methode ist das Präfix \\?\ die intern direkt übersetzt zu \??\ , der bei neueren Windows-Versionen mit \GLOBAL??\ identisch ist . Dies wird als Objektverzeichnis bezeichnet (bitte nicht mit Dateisystementitäten verwechseln , trotz ähnlicher Terminologie!). Auch hier können Sie mit WinObj und ähnlichen Tools den Namensraum des Objektmanagers untersuchen.
Zwischenspiel:Namespaces und Terminalserver-„Zeug“
Wer sich einmal mit der Geschichte von Windows NT befasst hat und Windows 10 seine Wurzeln auf NT zurückführt, wird sich an eine Zeit erinnern, als man Terminaldienste separat lizenzieren musste. Dh die Möglichkeit, sich mit verschiedenen Benutzern remote mit einem einzelnen Computer zu verbinden.
Ich denke, es war Windows XP, das dies endlich für die breite Masse brachte, indem es erlaubte, mit mehreren Benutzerkonten gleichzeitig angemeldet zu bleiben ("Benutzerwechsel"), und wahrscheinlich Windows 2000 oder 2003 Server enthielt dies in der Standardausgabe, obwohl CALs über das standardmäßig enthaltene Minimum an "Seats" hinaus benötigt wurden.
Hier wird zwischen \?? unterschieden und \GLOBAL?? stammt. \GLOBAL?? ist die Ansicht der von allen gemeinsam genutzten "DOS"-Gerätenamen Anmeldesitzungen.
\?? wird heutzutage im symbolischen Link gesehen (wieder keine Dateisystementität!). ) namens \DosDevices , was einen Hinweis auf seine Herkunft gibt. Hier stehen die "DOS"-Gerätenamen, wie zB C: oder Netzlaufwerkzuordnungen vorhanden sind. Auf einem modernen System C: wiederum wäre ein symbolischer Link zu \Device\HarddiskVolume1 (oder ähnliches). Das ist dann meist ein tatsächliches Geräteobjekt, das von einem Treiber im Speichertreiberstapel erstellt wurde, in diesem Fall sollte der NTFS-Dateisystemtreiber sein.
Wenn Sie also auf C:\Windows\explorer.exe doppelklicken Was intern passiert, ist, dass der Pfad konvertiert wird:
- Auf der Ebene des Win32-Subsystems besteht die übliche Änderung darin,
\??\voranzustellen . - Der Objektmanager erweitert dann den
\??\C:.- Zuerst
\??\landet im "DOS"-Gerätenamensraum für Ihre Anmeldesitzung (siehe Anmerkung unten) - Irgendwann findet der Objektmanager etwas wie
\??\C:heraus entspricht\GLOBAL??\C:was - wie wir oben gesehen haben - äquivalent zu\Device\HarddiskVolume1ist .
- Zuerst
Der Objektmanager übergibt dann den Rest des Pfades \Windows\explorer.exe an den für das Geräteobjekt \Device\HarddiskVolume1 zuständigen Treiber , um sicherzustellen, dass der Treiber weiß, auf welches Geräteobjekt verwiesen wurde. Und dieser Treiber wird wissen, wie er innerhalb seines eigenen Namensraums mit diesem bestimmten Rest des Pfads umgehen soll.
Anmerkung: Wenn Sie sich auf \?? beziehen intern erhalten Sie eine Ansicht der "DOS"-Geräte Ihrer lokalen Anmeldesitzung. Dies lässt sich am besten mit zugeordneten Netzlaufwerken erklären. Angenommen, Sie haben einen Laufwerksbuchstaben X: für eine Remote-Freigabe zugeordnet. Und sagen wir, Sie nutzen die „Benutzerumschaltung“ oder dies läuft auf einem bulligen Terminalserver, auf dem weitere zweihundert Benutzer gleichzeitig angemeldet sind. In einem solchen Szenario haben wir zwei Probleme. Während das Systemlaufwerk (z. B. eine physische Festplatte) von allen gemeinsam genutzt werden kann, hat möglicherweise jemand aus dem Vertrieb "die Umsatzanteil" als X: und jemand aus der Entwicklung hat möglicherweise "the gemappt Entwicklungsfreigabe". Gleiches gilt für einen über subst zugewiesenen "Laufwerksbuchstaben". . Dies sollte erklären, warum es keinen einzigen globalen Namensraum für "DOS"-Gerätenamen geben kann, der für alle passt.
Unser Ziel war es also, eine Datei zu erstellen (oder Verzeichnis) namens NUL und das Win32-Subsystem ließ uns nicht. Es hat einfach die Ausgabe geschluckt und die Datei wurde nie in unserem Arbeitsverzeichnis erstellt. Indem wir die Informationen aus dem oben verlinkten Artikel und dem vorherigen Zwischenspiel nutzen, können wir dies jedoch umgehen, indem wir diese lästigen Pfadkonvertierungen auf Subsystemebene umgehen, indem wir Folgendes ausgeben:
echo NONSENSE > \\?\%CD%\NUL
Zur Erinnerung:%CD% expandiert zum absoluten Pfad des aktuellen Arbeitsverzeichnisses und, vorausgesetzt, das ist C:\test , entspricht der obige Befehl echo NONSENSE > \\?\C:\test\NUL .
Und siehe da, ein schnelles dir beweist, dass die Datei erstellt wurde. Und wenn wir das mit anderen "reservierten" Namen versuchen, funktioniert es auch gut.
Bitte beachten Sie, dass Sie auch das aktuelle verwenden können native NT-Pfadform (\?? statt \\? ) für denselben Effekt:
echo NONSENSE > \??\%CD%\NUL
Ordentlich.
Wie wäre es also, wenn wir den abschließenden Punktversuch wiederholen, aber den vollständigen Pfad angeben, ohne dass das Win32-Subsystem eingreift?:
echo ILLEGAL TRAILING DOT > \??\%CD%\test.txt.
Voila, es funktioniert, als schnelles dir /b beweist:
C:\test>dir /b
CON
NUL
test.txt
test.txt.
Zwischenspiel:UNC-Pfade (Universal Naming Convention)
Dieses Thema wird in diesem Project Zero-Artikel ausführlicher behandelt, aber es genügt zu sagen, dass es eine spezielle Form von Pfad gibt, die dem, was wir gerade verwendet haben, ziemlich ähnlich sieht:\\.\C:\Windows\explorer.exe wäre ein Beispiel.
Erinnern Sie sich daran, dass Sie sich immer dann, wenn Sie auf dem Anmeldebildschirm stecken bleiben, nicht an den lokalen Computernamen des Computers erinnern und standardmäßig die Domäne verwenden, deren Mitglied er ist? Eine einfache Möglichkeit, auf den aktuellen Computer zu verweisen ohne auch nur den tatsächlichen Namen zu verwenden, ist .\username , wodurch auf den Benutzer username verwiesen werden kann auf der aktuellen Maschine .
Der . in \\.\C:\Windows\explorer.exe ist ähnlich zu verstehen. Was Sie sagen, ist \\. auf dem aktuellen Computer \C: auf Laufwerk C: Zugriffspfad \Windows\explorer.exe ... und die verschiedenen Möglichkeiten des Betriebssystems greifen ineinander, um dies zu ermöglichen.
Vorsicht :UNC-Pfade folgen anderen Regeln, weshalb ich sie nur erwähne. Lesen Sie den verlinkten Artikel und den Link zur Microsoft-Dokumentation, wenn Sie an weiteren Details interessiert sind.
Jetzt haben wir endlich eine "unmögliche" Datei test.txt. erstellt , sehen wir uns das mal an, okay?
C:\test>type test.txt
NONSENSE
Was zum Teufel? Ich erinnere mich deutlich daran, ILLEGAL TRAILING DOT wiederholt zu haben in diese Datei.
Ach, natürlich. So wie wir ursprünglich versucht haben, test.txt. zu erstellen das Win32-Subsystem griff erneut ein und wandelte unseren Namen "hilfreich" in test.txt um . Wir sehen uns also eigentlich \??\%CD%\test.txt an statt \??\%CD%\test.txt. .
Das sollte also reichen:
C:\test>type \??\%CD%\test.txt.
ILLEGAL TRAILING DOT
Viel besser. Das Problem ist, dass nicht alle Programme unser hinterhältiges Umgehen der Win32-Pfadnamenkonvertierungen so elegant wie cmd.exe handhaben . Angenommen, wir wollten Notepad öffnen:
C:\test>notepad \??\%CD%\test.txt.
Verdammt, wir sehen das folgende Meldungsfeld:
Es gibt also Möglichkeiten, einige zu umgehen Aufgrund der Einschränkungen, die das Win32-Subsystem auferlegt, ist der Nutzen dieser Methoden begrenzt und fragwürdig.
Hinweis :Leser, die sich auch entwickeln Software unter/für Windows kann dies mit dem Präfix \\?\ zurückrufen erlaubt, den MAX_PATH zu umgehen Limit (früher 260, im Grunde 255 plus \\?\ und ein abschließendes \0 ). Jetzt wissen Sie, warum wir damit ungefähr verwenden können 32767 Zeichen. Da UCS-2 durch UTF-16 ersetzt wurde (ich glaube in XP), ist die Pfadverstümmelung auf Objektmanagerebene nur ein Problem. Ein weiterer Grund ist, dass in UTF-16 ein Codepunkt mehr als 16 Bit einnehmen kann (auch bekannt als wchar_t oder WCHAR ), sobald Sie das BMP hinter sich gelassen haben.
Wie auch immer, die Befehlszeile (cmd.exe ) bietet Ihnen alle Tools, um auf Dateien zuzugreifen und sie zu entfernen, die Sie überhaupt von Windows aus erstellen konnten.
Linux/Samba-Freigabe, die vorgibt, NTFS zu sein
Verlassen wir nun das lokale Laufwerk und betrachten ein zugeordnetes Netzlaufwerk Z: , bereitgestellt von Samba 4.x, das für Windows ein NTFS-Laufwerk imitiert.
Dieses Experiment bietet einige weitere Einblicke, da wir Dateien nach den Regeln der Linux-Seite erstellen können und uns keine Sorgen machen müssen, dass wir von der Windows-Seite aus nicht darauf zugreifen können.
- Das zugeordnete Laufwerk ist
Z:und wir sind inZ:\testauf der Windows-Seite - Auf der Linux-Seite wurde das Volume als btrfs formatiert
Der Wikipedia-Artikel nennt uns alle Zeichen außer/und\0(auch bekannt als ASCII-NUL-Zeichen) sind erlaubt! Das soll also Spaß machen.
Hier sind einige extravagante Dateinamen, die auf der Windows-Seite schwer zugänglich sein sollten (oder zumindest könnten), indem Bash auf Ubuntu 20.04 auf der Linux-Seite verwendet wird, um sie zu erstellen:
:.txt(erstellt mitecho "$RANDOM" > \:.txt)???.txt(erstellt mitecho "$RANDOM" > \?\?\?.txt).txt(erstellt mitecho "$RANDOM" > .txt)*.txt(erstellt mitecho "$RANDOM" > \*.txt)\.txt(erstellt mitecho "$RANDOM" > \\.txt)".txt(erstellt mitecho "$RANDOM" > \".txt)>.txt(erstellt mitecho "$RANDOM" > \>.txt)<.txt(erstellt mitecho "$RANDOM" > \<.txt)|.txt(erstellt mitecho "$RANDOM" > \|.txt)
Dies sollte so ziemlich alle Grundlagen abdecken, eigentlich ist das Emoji beim zweiten Nachdenken vielleicht überhaupt kein Problem. Schrägstriche sind auch unter NTFS verboten, aber das gilt auch für btrfs/POSIX/SUS.
Beweis von der Linux-Seite:
$ find -type f -printf '%P\n'
:.txt
???.txt
.txt
*.txt
\.txt
".txt
>.txt
<.txt
|.txt
Mal sehen, ob und worauf wir auf der Windows-Seite zugreifen können ...
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 als Beweis:
Ohhhh! Richtig, das DOS-Erbe von Windows schlägt wieder zu. NTFS hat - sofern es nicht aktiv deaktiviert wird - die Fähigkeit, sogenannte 8.3-Kurzdateinamen zu erstellen, die den DOS-Anforderungen für Dateinamen entsprechen.
Und so können wir trotzdem auf die ungültigen Dateinamen zugreifen.
Schlussfolgerung
Jetzt erinnern Sie sich, die Frage bezog sich auf ein externes, dh lokales NTFS-Laufwerk. Das bedeutet, dass die Regeln, die wir gerade für Samba-Freigaben beobachtet haben, hier möglicherweise nicht gelten.
Abhängig vom Treiber, der zum Speichern dieser Dateien verwendet wird (der je nach Linux/macOS-Version variieren kann, z. B. ntfs-3g, oder dem verwendeten Treiber eines Drittanbieters, z. B. Paragon-Treiber), sehe ich die folgenden möglichen Ursachen, nachdem ich mir die obigen Experimente angesehen habe:
- der Dateiname enthielt einen
:,"oder?... dies erscheint mir am wahrscheinlichsten, da ich selbst versehentlich E-Book-Titel kopiert und eingefügt habe, die diese Zeichen enthalten. Wir können/so gut wie ausschließen und die anderen "verbotenen" Zeichen sind zumindest weniger wahrscheinlich. - Die Windows- und MacOS-Seite sehen den ungültigen Namen, versuchen Sie, den DOS 8.3-Namen zu sehen, aber es wurde keiner generiert. Dies hängt etwas von der genauen Windows-Version und ihrer Konfiguration ab, und da ich keine macOS-Geräte in der Nähe habe, kann ich dieses Szenario auch nicht testen. Außerdem bin ich mir nicht sicher, ob auf einem Windows-System mit 8.3 Namen aktiviert sind Windows würde rückwirkend einen 8.3-Namen generieren, wenn beispielsweise die Linux-Seite diesen Teil übersprungen hätte. Denn wenn ich mich richtig erinnere, entscheidet der NTFS-Treiber, ob der jeweilige Eintrag ("Attribut") belegt wird.
- Die Länge des Pfadnamens wurde überschritten. Ich halte das Überschreiten der Länge von Pfadsegmenten für unmöglich, da NTFS nicht zulässt, dass Sie mehr als 255 16-Bit-Werte für ein Pfadsegment speichern, aber die Gesamtpfadlänge möglicherweise auch überschritten wurde (siehe diesen Link). li>
Für das erste Szenario würde ich empfehlen, fslint auf der Linux-Seite zu verwenden, um die Datei- (und Ordner-) Namen zu bereinigen. Andere ähnliche Tools existieren und YMMV, treffen Sie eine Auswahl.
Hoffe das hilft. Es hat lange genug gedauert, meine Gedanken niederzuschreiben.
Weiterführende Literatur
- Dateien, Pfade und Namespaces benennen
- Der endgültige Leitfaden zur Pfadkonvertierung von Win32 nach NT