Es weiß sicherlich jeder oder fast Jeder das die Zeichen / \ : * ? " < > | in Dateinnamen nicht erlaubt sind.
z.B: Was? Warum auch immer! - Das ? wäre nicht erlaubt.
Warum auch immer. Wobei ein ! wiedrum erlaubt ist/sind.
Gibt es eine Möglichkeit Windows dazu bringen das er die Zeichen akzeptiert.
Könnte mir vorstellen dab man mit RegEdit man irgendwo herumschrauben muss oder so.
Wies ob das so wichtig ist ich benutze jetzt aktuell
Edition Windows 10 Pro
Version 22H2
Installiert am 30.05.2024
Betriebssystembuild 19045.5198
Leistung Windows Feature Experience Pack 1000.19060.1000.0
Gibt es eine Möglichkeit Windows dazu bringen das er die Zeichen
akzeptiert.
Nein, warum auch (zumindest nicht einfach so). Schließlich haben diese Zeichen unter Windows eine Sonderfunktion, die dir beim Handling mit Dateinamen mit solchen Zeichen einen ordentlichen Strich durch die Rechnung machen würden.
Weshalb Slash, Backslash und Sternchen nicht erlaubt sind, sollte sich durch Nachdenken von selbst ergeben. Pfadtrenner und Platzhalter gehören nicht in Dateinamen.
NATÜRLICH sind also die Wildcards und die Redirection-Zeichen und die
Pfadtrenner nicht erlaubt als Dateinamenbuchstaben.
Naja, die Shell und das Dateisystem sind aber zwei verschiedene Sachen. Das Dateisystem sollte eigentlich von der Shell keine Einschränkungen auferlegt bekommen, aber so hat wurde das damals unter DOS halt gemacht, und das hat sich bis heute so gehalten.
Eure Experimente mir Leerzeichen und Sonderzeichen könnt Ihr gern bis zum Ende machen. Beschwert Euch dann aber bitte nicht, wenn z.B. ein Backupprogramm die Hälfte Eures Mülls*.* nicht gesichert hat.
Wer nur Klicki-Bunti kennt, kennt natürlich keine Wildcards. Die
Dateisuche unter Windows funktioniert ja schon lange nicht mehr.
Doch, ist jetzt halt eher eine Filterfunktion im Dateiexplorer (nicht mehr gerade das was ich unter Suche verstehe, aber es geht zur not). Aber auch dort geht z.B. immer noch "*.mp?" als Filter. Da hat sich seit dem letzten Jahrtausend nichts dran geändert:-)
Und man wird es kaum glauben, das hat mit Windows noch nicht mal was zu tun. Das gibt es fast überall:
Man geht auch nicht bei ROT über die Straße. Warum wohl??
WENN er es unbedingt erforschen möchte, kann er sich mit regulären Ausdrücken und Maskierung beschäftigen. Aber wie schon geschrieben, sein Backup könnte mit Datenverlust ausfallen.
Geht, genau so lange, bis es beim Restore zufällig irgendetwas fehlt.
Warum sollte beim Restore etwas fehlen? Wenn, dann wäre die Backup-Software schuld, nicht der Nutzer.
Ich würde derartige Dateinamen nicht freiwillig benutzen, aber ich wüsste keinen Grund, warum mein Backup-System damit nicht klar kommen sollte.
Das rundherum wohl schwierigste Feature (manche würden es auch Misfeature nennen) an der Stelle sind Dateinamen, die Newlines enthalten. Geht auch, aber da würde ich tatsächlich nicht meine Perücke drauf verwetten, dass das Backup-Programm damit klar kommt.
In diesem Kontext finde ich den Unterstrich die sichere Lösung, sieht auf den üblichen displays aus wie ein Leerzeichen und ist problemlos zu kopieren, imho auf sämtlichen OS.
Windows und Android sind aber noch lange nicht "alle Systeme".
Unter Unixen sind nur / und \0 „ganz tief unten“ nicht erlaubt.
Dann wundert euch aber nicht, wenn euch Nicht-Unix-Nutzer anmeckern. ;)
Dass es erlaubt ist, heißt ja nicht, dass man es nutzen muss. Es geht wie schon gesagt eher darum, dass die Shell dem Dateisystem keine Beschränkungen auferlegen sollte.
Zumindest für Leerzeichen, '.', ':' etc:
Bei Leuten, die DVD-/BlueRay-Rips sammeln sind solche Dateinamen eher
die Regel als die Ausnahme ;-)
In Musik-Sammlungen ist das ebenso gängige Praxis.
Zumindest das Leerzeichen kann man doch leicht mit dem
ALT + 255 auf Zehnertastatur gut ersetzen. War schon damals
gängige Praxis, um in DOS Dateien (etwas) zu verstecken.
Klar, der Fachmann hatte das damals beim DIR sofort gemerkt,
da ja der Platz der Datei als leer angezeigt wurde und die
folgenden Dateien ja nicht an die Stelle nachgerückt sind.
In diesem Kontext finde ich den Unterstrich die sichere Lösung
Hab ich schon im vorigen Jahrtausend unter DOS so gemacht, und mach ich auch heute noch so.
Kein Leerzeichen, keine Sonderzeichen, keine Umlaute und kein"ß".
Geht, genau so lange, bis es beim Restore zufällig irgendetwas fehlt.
Warum sollte beim Restore etwas fehlen? Wenn, dann wäre die
Backup-Software schuld, "nicht der Nutzer".
Wer steht dann mit leeren Händen da? Der UNwissende Nutzer. Wenn unwiederbringliche Hochzeitsbilder und Dokumente verschwunden sind, wegen Sonderzeichen wirst Du viel Freude haben.
Ich würde gerne mal wissen wie viele tausende Personenjahre an Fehlersuche und Bugfixing weltweit Microsoft generiert hat, als sie Blanks in Dateinamen erlaubt haben.
Ich kenne das bei Kunden mit allen Arten von Klammer-Zeichen in Pfadnamen.
Der unwissende Nutzer hat eh keine Backups. Dass man sowas braucht, merkt er erst, wenn die Daten weg sind.
Ich bin bei der Vergabe von Dateinamen auch eher konservativ, das Thema war ja nur, dass es nicht „bei allen Systemen“ so ist, dass Dateisystem oder Betriebssystemfunktionen selbst dem Nutzer solche Einschränkungen auferlegen. Damit hat der Nutzer selbst die Freiheit zu entscheiden, was er gut findet und was nicht.
windows erkennt oder markiert mit manchen der zeichen ordner-datei-anfang-ende auf der festplatte. die dateien liegen als lange null-und-eins-reihen auf der festplatte, eigentlich alles sieht so aus. hier habe ich etwas gefunden, man muß schon sehr suchen : https://learn.microsoft.com/de-de/dotnet/standard/io/file-path-formats
es ist wie bei manchen programmiersprachen, oder auch den "regular expressions", manche zeichen sind fix mit einer aufgabe, funktion verknüpft, wie ein schalter. wenn man die zeichen dort trotzdem benutzen will, muß man sie "escapen".
Das Dateisystem sollte eigentlich von der Shell keine Einschränkungen
auferlegt bekommen, aber so hat wurde das damals unter DOS halt gemacht
Gewisse Einschränkungen machen durchaus Sinn, sonst wird dann bald noch verlangt, dass Emoticons oder Surrogate-Zeichen in Dateinamen vorkommen dürfen sollen.
Solange man keine Shell-Scripte darauf los lässt: kein Problem.
Da haben wir wieder die gewissen Einschränkungen ...
Natürlich kommen auch Shell Skripte damit klar, wenn sie richtig geschrieben wurden. Heisst, Sonderzeichen müssen Escaped werden. Man kann die in "" oder in '' packen, oder auch mit \ Escapen. Auch Kombinationen davon gehen. Normalerweise nutzt man '' und , bei "" kann man mit $ noch Variablen rein setzen.
Unter Linux kann man "einfach so" fast alle Sonderzeichen benutzen,
Emoticons sowieso.
Solange man keine Shell-Scripte darauf los lässt: kein Problem.
Nunja, bei Windows wird eben versucht, diese potentiellen Probleme durch Kollisionen mit der in der Text-Shell reservierten Zeichen proaktiv zu verhindern. Kommt mir irgendwie als durchaus sinnvolle Strategie vor.
Ich würde da eindeutig ein 1+ für das Windows-Konzept verteilen, wenn es mein Job wäre, die Konzepte zu vergleichen.
Übrigens: auf "unterster" Ebene (also im ntoskrnl) hat Windows exakt dieselben Einschränkungen für Dateinamen wie Linux. Es sind genau nur zwei Zeichen nicht erlaubt: Der Pfad-Delimeter und das Null-Zeichen.
Ersteres aus rein logischen Gründen, letzteres haben wir (bei Windows genauso wie bei Linux) den Einschränkungen der verwendeten Programmiersprache zu verdanken, also C.
Weil die halt eigentlich gar keine Strings kennt und als einzigen Notbehelf Null-Zeichen-terminierte Char-Arrays zu Verfügung stellt.
Besonders ärgerlich finde ich beim Abspeichern von e-mails automatisch generierte Dateinamen in denen Doppelpunkte ("Betreff:") und Senkrechtstriche (pipes) auftauchen. Damit geht der nächste Sicherungslauf erst mal schief...
Übrigens: auf "unterster" Ebene (also im ntoskrnl) hat Windows exakt
dieselben Einschränkungen für Dateinamen wie Linux.
Womit belegst du diese deine Behauptung?
Die unterste Ebene sind die Systemaufrufe (also nicht etwa ein physisches Schreiben auf das Medium selbst). Dort werden exakt die Zeichen als reserviert dargestellt, die im (möglicherweise Troll-)Eingangsposting genannt sind.
Also alle diese darfst du eben selbst auf der Ebene eines CreateFile2()-Syscalls nicht benutzen. (Außerdem reservieren sie bis auf Ausnahmefälle noch die Zeichen 1 bis 31.)
Das geht ja noch weiter mit historischem Ballast. Eine Datei namens "nul.txt" bekommst du unter Windows nie zu sehen …
Nunja, bei Windows wird eben versucht, diese potentiellen Probleme durch
Kollisionen mit der in der Text-Shell reservierten Zeichen proaktiv zu
verhindern. Kommt mir irgendwie als durchaus sinnvolle Strategie vor.
Wenn der Explorer, Die Dateidialoge, die Shells und vermutlich noch jede
Menge weiterer Anwendungen mit diesen Zeichen nicht zurechtkommen, wäre
es konsequenter zielführender, die Restriktion direkt in der gemeinsamen
Basis, nämlich dem Filesystem unterzubringen. Damit wäre garantiert,
dass die verbotenen Zeichen niemals in einem Dateinamen landen können,
egal wie buggy die darüberliegende Software ist.
Noch besser wäre es natürlich, wenn Microsoft den Explorer und die
Shells dahingehend überarbeiten würde, dass die Restriktionen gar nicht
erst nötig sind (Unix/Linux zeigt ja, wie das geht). Da da aber gerade
beim Explorer und cmd.exe wohl viel Legacy-Software im Spiel ist, deren
Entwickler längst geflüchtet sind, wird sich da wohl keiner heranwagen.
Übrigens: auf "unterster" Ebene (also im ntoskrnl) hat Windows exakt
dieselben Einschränkungen für Dateinamen wie Linux. Es sind genau nur
zwei Zeichen nicht erlaubt: Der Pfad-Delimeter und das Null-Zeichen.
Gleiches gilt auch für NTFS, das ebenfalls nichts von den verbotenen
Zeichen weiß, und genau hier liegt das Problem:
Ohne viel Trickserei und völlig NTFS-konform kann ein Dateiname erzeugt
werden, der den Rest des Systems in arge Verlegenheit bringt. Man muss
dazu nicht einmal auf "unterster" Ebene herumprogrammieren. Es genügt
schon, einen mit NTFS formatierten USB-Stick auf einem Nicht-Windows-PC
entsprechend zu beschreiben, was auch ohne böse Absicht passieren kann.
Beispiel:
Ich möchte mittels NTFS-USB-Stick Messdaten von einem Linux-basierten
Labor-PC auf einen Windows-basierten Büro-PC kopieren. Die Daten liegen
in zwei Dateien namens
"Messung für t<1000s.dat"
und
"Messung für t>=1000s.dat"
vor. Beide Namen sind sowohl Linux- als auch NTFS-konform.
Ich kopiere sie ins Root-Verzeichnis des USB-Sticks, wo schon andere
Dateien liegen. Im Windows-Explorer poppt eine Meldung auf, wonach der
USB-Stick nicht lesbar oder korrupt sei.
Da auch auf die bereits existierenden Dateien nicht mehr zugegriffen
werden kann, vermutet der unbedarfte Windows-User ein Problem mit dem
USB-Stick und formatiert ihn neu oder schmeißt in gleich ganz weg.
Tatsächlich sind aber sowohl der USB-Stick als auch die darauf
befindlichen Daten noch völlig in Ordnung.
Wenn ich den USB-Stick wieder in den Linux-PC stecke und die beiden
Dateien passend umbenenne, funktioniert er anschließend auch unter
Windows wieder perfekt.
Für mich sieht es so aus, als würde der Dateibaum Regex-ähnlich durchsucht werden können sollte. Darf man das so sagen ?
Oder will man verhindern, daß im Dateibaum in File-namen Programminstruktionen Befehle stehen können ?
Der (Windows-)Rechner meiner Frau ist auf rumänisch eingestellt, und am Anfang hat sie Dateien mit den rumänischen Sonderzeichen benannt. Das führte dann zu Problemen auf dem Server dass ich die Dateien von meinem Rechner nicht mehr sah oder löschen konnte. Bin mir jetzt nicht mehr sicher.
Dasselbe aus chinesischen DLs mit ihren lustigen Dateinamen, musste ich alle löschen oder umbenennen!
Seit einiger Zeit habe ich mir angewöhnt sämtliche Dateien und Verzeichnisse ohne Spaces zu benennen, stattdessen mit "_".
Wenn der Explorer, Die Dateidialoge, die Shells und vermutlich noch jede
Menge weiterer Anwendungen mit diesen Zeichen nicht zurechtkommen, wäre
es konsequenter zielführender, die Restriktion direkt in der gemeinsamen
Basis, nämlich dem Filesystem unterzubringen.
Warum sollte der Explorer und die ganzen anderen graphischen Anwendungen Probleme mit Zeichen wie > haben? Der einzige Grund, warum das Zeichen verboten ist, ist, weil es auf der Shell für redirect von stdout verwendet wird. Bei einem : sehe ich es ja noch ein. Das braucht man halt, weil Windows es bis heute noch nicht geschafft hat, von den alten Laufwerksbuchstaben loszukommen. Das ist nicht shell-spezifisch.
Übrigens: Unter DOS war auch das + in Dateinamen verboten, weil man mit dem Shell-Kommando COPY mit der etwas kruden Syntax
1
copy a.txt+b.txt c.txt
zwei Dateien konkatenieren konnte.
Gleiches gilt auch für NTFS, das ebenfalls nichts von den verbotenen
Zeichen weiß, und genau hier liegt das Problem:
NTFS kann vieles, z.B. auch Symlinks, aber Windows hat es nie geschafft, die auch nur annähernd brauchbar ins System zu integrieren.
Es genügt schon, einen mit NTFS formatierten USB-Stick auf einem Nicht
-Windows-PC entsprechend zu beschreiben, was auch ohne böse Absicht
passieren kann.
Spaßig wird es auch, wenn man z.B. zwei Dateien names Hallo.txt und hallo.txt anlegt.
Vermutlich „gewinnt“ dann die, die im Verzeichnis physisch zuerst steht.
;-)
So scheint es tatsächlich zu sein :)
Es wirkt schon etwas befremdlich, wenn man im Explorer eine Datei
doppelklickt, aber eine ganz andere geöffnet wird. Wirklich spooky wird
es, wenn man eine Datei umbenennt oder löscht und die Operation nicht
auf der ausgewählten Datei, sondern auf einer an anderer Stelle in der
Auflistung stehenden Datei ausgeführt wird, wobei die ausgewählte Datei
unverändert stehen bleibt =8-o
Irgendwie passen Windows und NTFS nicht wirklich gut zusammen, auch wenn
in einer Windows-Only-Welt lebende Leute nicht viel davon mitbekommen.
Mir scheint, dass die NTFS-Entwickler damals voller Enthusiasmus
vorgeprescht sind, ohne auf die behäbigeren Shell-Entwickler Rücksicht
zu nehmen. Da sich diese überrannt gefühlt haben, haben sie – statt ihre
Softwarekomponenten entsprechend anzupassen – aus Trotz zum Gegenschlag
ausgeholt und die VFAT-Erweiterung für die klassischen FAT-Filesysteme
entwickelt, um auch ohne NTFS lange Dateinamen zu ermöglichen. Die
Implementierung von VFAT ist zwar ziemlich murksig (für die Speicherung
langer Dateinamen werden versteckte Volume-Label-Einträge missbraucht),
dafür aber weitgehend abwärtskompatibel.
Mir scheint, dass die NTFS-Entwickler damals voller Enthusiasmus
vorgeprescht sind, ohne auf die behäbigeren Shell-Entwickler Rücksicht
zu nehmen.
NTFS ist halt HPFS, welches für OS/2 als gemeinsames Projekt von IBM und Microsoft konzipiert war. Bei Windows ist dann außer dem Filesystem nur nichts mehr groß sonst davon übrig geblieben.
Wäre ja sicher auch noch lustig, das Ganze dann nochmal unter WSL anzusehen. Kann man dort eigentlich ein aux.c anlegen? (Eine Datei mit diesem Namen hatte ich in den Tests von AVR-LibC mit drin, und es brachte mir dann irgendwann einen Bugreport ein, weil man das unter Windows nicht auschecken konnte.)
Die ganze Sache wird besonders lustig, wenn Du WSL laufen hast und ein
EXT4 Volume ins Dateisystem einbindest.
Dann bricht für Win die Hölle los.
Das klingt aber spannend, wie darf man sich das vorstellen?
Cygwin hatte zwar auch den ein oder anderen Bug, vor allem im Umgang mit Edits in Editoren, aber so unterm Strich war Cygwin oft eine positive Überraschung, und teilweise auch recht lustig bzw. unterhaltsam.
Ein anderer Punkt ist natürlich noch die Programmiersprachenlogistik bei C.
Man muss sich halt festlegen, welche Zeichen in der Compilerauswertung Steuerzeichen (und keine "Daten") sein sollen (oder können..).
Diese Art von Festsetzungen geht bei Programmiersprachen oft noch bis in die Variablen-Namen-Vergebung.
C hat mit seiner Auswahl und dem Sprachdesign aber auch ein hohes Maß an Standardisierung mitgebracht.
Andere Sprachen wie Assembler oder Lisp sind weniger standardisiert, deswegen aber auch sehr Dialektanfällig und so gibt es oft viele Versionen.
Bei Assembler z.B. Masm, Tasm, Nasm usw, dann auch noch die AT&T Syntax und Lisp hat eben viele Neuschaffungen wie Rust, Haskell oder OCaml und viele weitere "Programmiersprachen"(- Ideen) auf dieser Basis.
"Known problems
Character translation must be used to accommodate filenames which include a colon (:) or other characters that do not comply with the naming conventions of Windows file-systems. Files with the same name but different cases are also not allowed by default, but can be enabled on installation with the side-effect of making the underlying partition's filesystem case-sensitive,[6][7] even for the Win32 subsystem.
Network authentication for UNIX systems relies on the insecure NIS protocol (LDAP- and Kerberos-based authentication require a third-party solution). Microsoft has released several hotfixes for Windows Services for UNIX, and at least one Security Update (KB939778). The GNU Project utilities are several versions older than the latest ones. A separate port of the up-to-date Debian utilities was started in 2007, but apparently abandoned in 2009.[8] Several of the text processing utilities in SUA (e.g. awk) are not compatible with Unicode or wide character text files."
aus:
https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
Spaßig wird es auch, wenn man z.B. zwei Dateien names Hallo.txt und
hallo.txt anlegt.
Kann dir eben unter Win32 nicht passieren. Genau das ist der Trick. Es werden schon beim Schreiben all die bestehenden Restriktionen beachtet, so dass fehlerträchtiger Mist erst garnicht auf dem Datenträger landen kann.
Im Übrigen erschließt ich mir auch nicht der tiefere Sinn der gleichzeitigen Existenz von "Hallo.txt" und "hallo.txt" in einem einzigen Verzeichnis. Wozu soll das gut sein?
Im Übrigen erschließt ich mir auch nicht der tiefere Sinn der
gleichzeitigen Existenz von "Hallo.txt" und "hallo.txt" in einem
einzigen Verzeichnis. Wozu soll das gut sein?
Es spart CPU, da beim createFile nicht mehr auf Duplikate in allen möglichen Groß-/Kleinschreibungsvarianten geprüft werden muss.
Im Ernst - was soll der tiefere Sinn sein, dies explizit zu beschränken?
