Erzwingen von Zeichen in Dateinamen Hallo Leute 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 Danke an alle im voraus
Matthias 🟠. schrieb: > Nein, es gibt keine Möglichkeit das zu ändern. Was ich wirklich bedaure... Ersatzweise "Format C:\ /Y"? ;DDD
Michelle P. schrieb: > 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.
Michelle P. schrieb: > Warum auch immer. Ja, warum wohl ? Nennst du deine Datei test*.tx? und willst sie löschen del test*.tx? dann löscht das System auch test21.txt und testall.tx einfach so gleich mit. NATÜRLICH sind also die Wildcards und die Redirection-Zeichen und die Pfadtrenner nicht erlaubt als Dateinamenbuchstaben. Wer nur Klicki-Bunti kennt, kennt natürlich keine Wildcards. Die Dateisuche unter Windows funktioniert ja schon lange nicht mehr.
Michael B. schrieb: > Die Dateisuche unter Windows funktioniert ja schon lange nicht mehr. Mit einem vernünftigen Dateimanager dürfte es noch funktionieren.
Michael B. schrieb: > 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.
René H. schrieb: > Aber unter allen Systemen. Nö. Unter Unixen sind nur / und \0 „ganz tief unten“ nicht erlaubt.
1 | $ echo blabla > 'Was zum Geier™ soll der ganze Schei*** hier eigentlich?!¬1^???' |
2 | $ ls -l Was* |
3 | -rw-r--r-- 1 j wheel 7 Dec 9 22:36 Was zum Geier™ soll der ganze Schei*** hier eigentlich?!¬1^??? |
4 | $ rm Was* |
Geht doch :-)
René H. schrieb: > Rolf M. schrieb: >> und das hat sich bis heute so gehalten. > > Aber unter allen Systemen. Nö.
Lu schrieb: > Eure Experimente mir Leerzeichen Das wird einer der Gründe sein, weshalb Leerzeichen in URLs maskiert werden müssen, wenn man schon meint, Leerzeichen in Zielen nutzen zu müssen.
:
Bearbeitet durch User
Rolf M. schrieb: > René H. schrieb: >> Rolf M. schrieb: >>> und das hat sich bis heute so gehalten. >> >> Aber unter allen Systemen. > > Nö. In Android sind sie auch nicht erlaubt. > Unter Unixen sind nur / und \0 „ganz tief unten“ nicht erlaubt. Dann wundert euch aber nicht, wenn euch Nicht-Unix-Nutzer anmeckern. ;)
Jörg W. schrieb: > Geht doch :-) Wer sich nicht an Spielregeln hält, muß mit den Folgen später leben. Geht, genau so lange, bis es beim Restore zufällig irgendetwas fehlt.
Michael B. schrieb: > 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: - https://geek-university.com/wildcards/ - http://www.willemer.de/informatik/unix/wildcard.htm - https://www.oreilly.com/library/view/learning-unix-for/0596006179/ch04s02.html
René H. schrieb: > den Grund dafür wissen 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.
Irgend W. schrieb: > Aber auch dort geht z.B. immer noch "*.mp?" als Filter. Na ja, das ist weit entfernt von einer sinnvollen Dateisuche wie sie z.B. unter Win95 noch vorhanden war. Und weit entfernt von dem, was Apples Dateisuche kann, die wirklich genial ist.
Lu schrieb: > 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.
Jörg W. schrieb: > Ich würde derartige Dateinamen nicht freiwillig benutzen 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.
:
Bearbeitet durch User
Harry L. schrieb: > In Musik-Sammlungen ist das ebenso gängige Praxis. Weil die so besser lesbar sind als ohne Leerzeichen.
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.
René H. schrieb: >>> Aber unter allen Systemen. >> >> Nö. > > In Android sind sie auch nicht erlaubt. 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.
Harry L. schrieb: > 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.
Michelle P. schrieb: > Gibt es eine Möglichkeit Windows dazu bringen das er die Zeichen > akzeptiert. Nein, das sind Altlasten aus DOS-Zeiten die immer noch mitgeschleppt werden.
:
Bearbeitet durch User
Mark S. schrieb: > 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"ß".
Jörg W. schrieb: >> 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.
Lu schrieb: > Der UNwissende Nutzer. 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.
Harry L. schrieb: > Jörg W. schrieb: >> Ich würde derartige Dateinamen nicht freiwillig benutzen > > 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. Diesbezüglich habe ich gute Erfahrungen mit detox [1] gemacht. HTH, YMMV. [1] https://sourceforge.net/projects/detox/
Ein Programm kann Dateien erzeugen die die Shell / der Dateimanager nicht bearbeiten kann. Hat mich mal eine mühselige Umbenneungsorgie gekostet.
Mit dem Befehl ren kann man Geisterfahrer in Dummheit ändern. Im wahren Leben sind die Folgen extremer.
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".
:
Bearbeitet durch User
Rolf M. schrieb: > 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.
Angehängte Dateien:
-
2024-12-10_16-14.png
22 KB
Unter Linux kann man "einfach so" fast alle Sonderzeichen benutzen, Emoticons sowieso. Solange man keine Shell-Scripte darauf los lässt: kein Problem.
:
Bearbeitet durch User
Sherlock 🕵🏽♂️ schrieb: > Solange man keine Shell-Scripte darauf los lässt: kein Problem. Da haben wir wieder die gewissen Einschränkungen ...
Carypt C. schrieb: > windows erkennt oder markiert mit manchen der zeichen > ordner-datei-anfang-ende auf der festplatte. Blödsinn. Zu FAT-Zeiten wurden freie und gelöschte Directory-Einträge am ersten Byte des Dateinamens erkannt, die übrigen Metadaten waren aber davon getrennt. Carypt C. schrieb: > die dateien liegen als lange null-und-eins-reihen auf der festplatte, > eigentlich alles sieht so aus. "Computer für Grundschüler, Band 1"? Bist Du eigentlich mit "Schlaumaier" verwandt?
:
Bearbeitet durch User
Jens G. schrieb: > Sherlock 🕵🏽♂️ schrieb: >> 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.
Carypt C. schrieb: > Hmmm schrieb: >> Blödsinn. > > wolltest du dich nicht zum thema äußern oder nur grundschüler bashen ? Vielleicht findest du ja für deine recht wild aufgestellten Behauptungen noch irgendwelche Belege, die nachweisen, dass sie kein Blödsinn sind?
:
Bearbeitet durch Moderator
Carypt C. schrieb: > Soll doch Hmmm belegen, daß er keinen Quatsch schreibt. Man kann die Nichtexistenz von etwas nicht beweisen. Stichwort: Russels Teekanne https://de.wikipedia.org/wiki/Russells_Teekanne
Sherlock 🕵🏽♂️ schrieb: > 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...
Ob S. schrieb: > Ü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. https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
1 | The following reserved characters: |
2 | |
3 | < (less than) |
4 | > (greater than) |
5 | : (colon) |
6 | " (double quote) |
7 | / (forward slash) |
8 | \ (backslash) |
9 | | (vertical bar or pipe) |
10 | ? (question mark) |
11 | * (asterisk) |
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 …
Ob S. schrieb: > 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 "_". Gruss Chregu
Jörg W. schrieb: > Das geht ja noch weiter mit historischem Ballast. Eine Datei namens > "nul.txt" bekommst du unter Windows nie zu sehen … Versuche mal, ein Verzeichnis namens Prn zu erzeugen. Yalu X. schrieb: > 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.
:
Bearbeitet durch User
Rolf M. schrieb: > 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. ;-)
Rolf M. schrieb: > Spaßig wird es auch, wenn man z.B. zwei Dateien names Hallo.txt und > hallo.txt anlegt. Allerdings. hab's gerade mal ausprobiert :) Jörg W. schrieb: > 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.
Yalu X. schrieb: > 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.
Jörg W. schrieb: Ob S. schrieb: > Übrigens: auf "unterster" Ebene (also im ntoskrnl) hat Windows exakt > dieselben Einschränkungen für Dateinamen wie Linux. > Die unterste Ebene sind die Systemaufrufe Ja. > https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file "win32"->falsches Level. Eins zu hoch.
Max H. schrieb: > 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. Beim DOS waren die Strings übrigens per DOS-Interrupt noch Dollar-Zeichen-Terminiert. Mit entsprechendem KnowHow auf der Systemebene (das halt nicht jeder hat) kann man auch Passwortcracker länger rechnen lassen. (u.a. auch: https://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange) 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.
Jörg W. schrieb: > Welches API-Level befindet sich darunter? Ich würde mal vermuten, NTAPI. http://undocumented.ntinternals.net/
"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
Rolf M. schrieb: > 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?
Ob S. schrieb: > 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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.