wollte eben eine Angebotsseite bei Ebay speichern. Geht auch wie üblich, nur fand sich die Seite dann nirgends. Allerdings fand sich ein kleines oranges Symbol neben dem Download-Symbol (Bild).
Bedeutung des Symols: Download fehlgeschlagen.
Kann ein Seitenanbieter neuerdings das Speichern seiner Seite verhindern?
Habe also mal alles mögliche probiert und komme zu folgendem Ergebnis: Ebay verwendet in dem vorgeschlagenen Dateinamen einen senkrechten Strich (Beschreibung | eBay.html), dem USB-Stick, auf den ich speichern wollte, gefällt das wohl nicht. Wenn ich unter Ubuntu den Standardpfad nutze (/home/nutzer/Downloads/), dann klappt das Speichern der Seite wie gewohnt.
Allerdings gibt es dann beim Verschieben der Dateien auf den USB-Stick eine Fehlermeldung. Man muss vor dem Speichern den senkrechten Strich aus dem vorgeschlagenen Dateinamen entfernen, dann klappt es hier in alle Richtungen.
Habe also mal alles mögliche probiert und komme zu folgendem Ergebnis:
Ebay verwendet in dem vorgeschlagenen Dateinamen einen senkrechten
Strich (Beschreibung | eBay.html), dem USB-Stick, auf den ich speichern
wollte, gefällt das wohl nicht.
Dem Stick selber ist das so hoch wie breit. Der bekommt von Dateinamen überhaupt nichts mit. Wenn, dann ist das ein Problem des Filesystemtreibers.
Und ja: könnte gut sein, dass der den für Ex(FAT) illegalen Dateinamen nicht akzeptiert, wie es sich mit an Sicherheit grenzender Wahrscheinlichkeit auf dem Stick befindet.
Habe also mal alles mögliche probiert und komme zu folgendem Ergebnis:
Ebay verwendet in dem vorgeschlagenen Dateinamen einen senkrechten
Strich (Beschreibung | eBay.html), dem USB-Stick, auf den ich speichern
wollte, gefällt das wohl nicht. Wenn ich unter Ubuntu den Standardpfad
nutze (/home/nutzer/Downloads/), dann klappt das Speichern der Seite wie
gewohnt.
Das spricht dann nicht für Firefox, denn der sollte Sonderzeichen in Dateinamen sinnvoll "Escapen" bzw. ersetzen. Aber dann müssten die Programmierer sich ja Gedanken um Einschränkungen von Datei- und Pfadnamen machen, und das womöglich über mehrere Betriebs- und Dateisysteme hinweg.
Manch ein Hobbyprogrammierer kann solche Anforderungen mit Arroganz beseitewischen und sagen, daß Dateisysteme, die solche Vorgaben machen, halt irgendein dummer Microsoft-Kram wären, aber bei den Entwicklern, die an Firefox und ähnlichen Projekten für mehrere Plattformen arbeiten, sollte man etwas mehr Fähigkeit zum Blick über den eigenen Tellerrand erwarten können. Der Aufwand, Dateinamen zu säubern, wäre nicht groß, und könnte problemlos auf einen gemeinsamen Nenner zusammengefasst werden, d.h. die resultierenden Dateinamen wären mit /allen/ rezenten Datei- und Betriebssystemen kompatibel.
Aber dann müssten die
Programmierer sich ja Gedanken um Einschränkungen von Datei- und
Pfadnamen machen
Haben Sie. Sogar mehr als von dir gefordert. Statt kleinstem gemeinsamen Nenner (7-Bit-Ascii-Filenames only, 8.3-Konvention?) verwenden Sie auf jedem System die dort geltenden Einschränkungen.
Wenn du auf deinem Rechner zusätzliche Einschränkungen einführst, außerhalb der Kontrolle von Firefox, warum sollten die das proaktiv berücksichtigen?
Wenn ich morgen ein eigenes Dateisystem veröffentliche, was nur Dateien mit Namen 0..9 erlaubt, soll Firefox das dann verpflichtend für alle Betriebssysteme berücksichtigen, und nie mehr andere Dateinamen erlauben?
Haben Sie. Sogar mehr als von dir gefordert. Statt kleinstem gemeinsamen
Nenner (7-Bit-Ascii-Filenames only, 8.3-Konvention?) verwenden Sie auf
jedem System die dort geltenden Einschränkungen.
Nein, tun sie ja ganz offenkundig nicht, sonst wäre Firefox ja in der Lage, seinen Krempel auch auf dem USB-Stick zu speichern.
Und genau das ist diese spezifische Form von Hobbyprogrammiererarroganz, die ich meine. Der USB-Stick kommt mit einem von Ubuntu unterstützten Dateisystem, das ist keine Eigenbastelei, keine willkürliche und abstruse Einschränkung, sondern einfach nur ein anderes Dateisystem.
Und daß man sich beim Beschreiben eines Dateisystems an die vom Dateisystem vorgegebenen Beschränkungen hält, ist ja wohl 'ne Selbstverständlichkeit.
Nein, tun sie ja ganz offenkundig nicht, sonst wäre Firefox ja in der
Lage, seinen Krempel auch auf dem USB-Stick zu speichern.
Doch, tun sie ganz offensichtlich. In deinem ~/Download funktioniert's ja.
Was nicht funktioniert, ist dass dein Dateisystem auf deinem USB-Stick sich an die Linux-Konventionen bzgl. erlaubter Zeichen im Dateinamen und der zwingenden Unterscheidung von Groß/Kleinbuchstaben hält.
Und Workarounds für derartige Einschränkungen sollten nie Sache der Anwendung sein.
Wenn du das Problem lösen willst: FUSE erlaubt stackable modules. Bastel dir ein kleines Modul dazwischen, was dir die Dateinamen so auf FAT, VFAT, exFAT oder sonstwas umschreibt, wie du dir das vorstellst.
Was nicht funktioniert, ist dass dein Dateisystem auf deinem USB-Stick
sich an die Linux-Konventionen bzgl. erlaubter Zeichen im Dateinamen und
der zwingenden Unterscheidung von Groß/Kleinbuchstaben hält.
Der Aufwand, Dateinamen zu säubern, wäre nicht groß, und könnte
problemlos auf einen gemeinsamen Nenner zusammengefasst werden, d.h. die
resultierenden Dateinamen wären mit allen rezenten Datei- und
Betriebssystemen kompatibel.
Ich will nicht, dass Firefox an den Dateinamen unnötige Änderungen macht, nur weil es irgendwo ein (von mir dafür nicht genutztes Dateisystem) gibt, das mit dem Namen sonst nicht klar käme.
Und daß man sich beim Beschreiben eines Dateisystems an die vom
Dateisystem vorgegebenen Beschränkungen hält, ist ja wohl 'ne
Selbstverständlichkeit.
Ja, an die von genau diesem Dateisystem vorgegebenen Beschränkungen von mir aus schon. Aber nicht an die Beschränkungen aller möglichen Dateisysteme gleichzeitig.
Was nicht funktioniert, ist dass dein Dateisystem auf deinem USB-Stick
sich an die Linux-Konventionen bzgl. erlaubter Zeichen im Dateinamen und
der zwingenden Unterscheidung von Groß/Kleinbuchstaben hält.
Meinst Du das wirklich ernst?
Warum nicht? Bei Linux ist in Dateinamen alles außer dem '' erlaubt. Wenn du jetzt einen USB-Stick mit einem Dateisystem hast, das sich daran nicht hält, warum sollte das dann ein Problem von Firefox sein?
Ist das jetzt ein Fehler vom "mv"-Utility oder eine Einschränkung vom
Dateisystem?
Das ist eine Einschränkung des Dateisystems. Und letztlich ein Fehler in der Implementierung von "mv" (oder anderen Tools, die mit Dateinamen hantieren), daß es sich nicht um die Gepflogenheiten des Zieldateisystems kümmert, /obwohl/ das Zieldateisystem vom verwendeten Betriebssystem unterstützt wird.
Man kann jetzt den Hobbylinuxprogrammierer geben und mit dem Fuß aufstampfen und zetern, daß Linux alles richtig und alle anderen alles falsch machen, aber das ist ... halt auch nicht zielführend.
Und dem Menschen, der einfach nur eine Datei mit seinem Webbrowser auf einem USB-Stick speichern will, exakt überhaupt nicht weiterhilft.
Wie argumentierst Du eigentlich, wenn über eine Netzwerkverbindung auf andere Systeme zugegriffen wird? Ist da auch alles falsch, was sich nicht an Deine "Linux-Gepflogenheiten" hält?
Ja, klar, man kann an dieser autistischen Sichtweise festhalten, dann aber sollte man konsequent sein und /jede/ Unterstützung für andere als native Linux-Dateisysteme rauswerfen und natürlich auch Samba & Co.
Das ist eine Einschränkung des Dateisystems. Und letztlich ein Fehler in
der Implementierung von "mv" (oder anderen Tools, die mit Dateinamen
hantieren), daß es sich nicht um die Gepflogenheiten des
Zieldateisystems kümmert, obwohl das Zieldateisystem vom verwendeten
Betriebssystem unterstützt wird.
Was soll mv denn dagegen tun?
Man kann jetzt den Hobbylinuxprogrammierer geben und mit dem Fuß
aufstampfen und zetern, daß Linux alles richtig und alle anderen alles
falsch machen, aber das ist ... halt auch nicht zielführend.
Es bist eher du, der hier mit dem Fuß aufstampft und zetert, nämlich dass Firefox und mv angeblich kaputt seien und doch "repariert" werden müssten, weil dein USB-Stick mit bestimmten Dateinamen nicht klar kommt.
Genauso gut könntest du dem Webserver die Schuld geben, dass dessen Seiten Namen tragen, die man nicht auf jedem System so speichern kann.
Und dem Menschen, der einfach nur eine Datei mit seinem Webbrowser auf
einem USB-Stick speichern will, exakt überhaupt nicht weiterhilft.
Wie argumentierst Du eigentlich, wenn über eine Netzwerkverbindung auf
andere Systeme zugegriffen wird? Ist da auch alles falsch, was sich
nicht an Deine "Linux-Gepflogenheiten" hält?
Du bist derjenige, der sagt, dass alles falsch sei, was sich nicht an die Gepflogenheiten eines bestimmten Systems hält.
Ja, klar, man kann an dieser autistischen Sichtweise festhalten, dann
aber sollte man konsequent sein und jede Unterstützung für andere als
native Linux-Dateisysteme rauswerfen und natürlich auch Samba & Co.
Nö. Man kann auch einfach alles so lassen, wie es ist.
Das Verhalten von Firefox und Linux ist schon richtig.
Man kann jetzt durchaus darüber diskutieren ob Firefox nicht bessere Fehlermeldungen anzeigen kann.
Aber was wäre die Alternative?
Nur Dateinamen akzeptieren die überall gehen -> 8.3 Zeichenlimit. Aber das will außer DOS Nutzern doch niemand mehr.
Die Abstraktion des Dateisystems aufbrechen - sprich es müsste für jeden Ordner einen Betriebssystem Aufruf geben, der die Eigenschaften (Erlaubte Zeichen, Länge, etc) des jeweiligen Ordners der Anwendung mitteilt. Könnte man machen. Das hat dann aber so lustige Effekte wie "Der Nutzer gibt einen eigenen Namen ein, der vom derzeitig ausgewählten Ordner unterstützt wird -> Wählt dann einen anderen Ort, der weniger kann -> Firefox muss den vom Nutzer angegebenen Name ändern oder mit einer Fehlermeldung auf das Problem hinweisen." Ob das jetzt nicht auch neue Probleme verursacht?
dann aber sollte man konsequent sein und jede Unterstützung für andere
als native Linux-Dateisysteme rauswerfen und natürlich auch Samba & Co.
Nö. Man kann auch einfach alles so lassen, wie es ist.
Warum aber gibt Ubuntu vor, andere Dateisysteme zu unterstützen?
Weil es das tut. Du kannst darauf Dateien speichern und von dort lesen. Und es gelten dafür dann auch die gleichen Einschränkungen wie sie das Dateisystem vorgibt. Was es eben nicht unterstützt, ist eine automatische Verfälschung der Dateinamen, um die Beschränkungen bestimmter Dateisysteme zu umgehen.
Ebay verwendet in dem vorgeschlagenen Dateinamen einen senkrechten
Strich (Beschreibung | eBay.html), dem USB-Stick, auf den ich speichern
wollte, gefällt das wohl nicht.
Du bist doch nicht gezwungen, den beim Speichern vorgeschlagenen
Dateinamen zu benutzen, du kannst dir doch selbst einen Dateinamen
ausdenken. Ich mache das fast immer, wenn ich was aus dem Internet
speichere, da entferne ich auch gleich Leerzeichen und Sonderzeichen.
Leerzeichen ersetze ich mit einen Unterstrich.
Und Seiten speichere ich in PDF-Dateien, da hat man dann nur
eine Datei.
Strg+p und dann auf "In Datei drucken" klicken, Wunschdateiname
eintragen und auf Drucken klicken.
Allerdings gibt es dann beim Verschieben der Dateien auf den USB-Stick
eine Fehlermeldung. Man muss vor dem Speichern den senkrechten Strich
aus dem vorgeschlagenen Dateinamen entfernen, dann klappt es hier in
alle Richtungen.
Du bist doch nicht gezwungen, den beim Speichern vorgeschlagenen
Dateinamen zu benutzen, du kannst dir doch selbst einen Dateinamen
ausdenken.
Kann man machen, aber in dem Angebotstext standen die wesentlichen techn. Daten zum Artikel, zu was den Text ändern? Eigentlich bin ich mit Windows unterwegs, da war das Speichern einer Seite unter Firefox nie ein Problem.
Aber ist der eigentlich Schuldige nicht Ebay?
Zu was dieses "|" im Seitennamen?
Man kann jetzt durchaus darüber diskutieren ob Firefox nicht bessere
Fehlermeldungen anzeigen kann.
Berechtigter Vorwurf. Nur einen winzigen orangen Punkt zu setzen und die Speicherung nicht durchzuführen ist nicht so der Hit. Eine Warnmeldung (Speichern nicht möglich, weil...) wäre sicher zielführender.
Bei mir (Debian) habe ich ebenfalls das Problem, dass Firefox ganz viele Seiten nicht speichern kann und dann "fehlgeschlagen" kommt. Bestimmt über 50% der Seiten.
Firefox ist m.W.n. nicht als snap installiert und Firefox hat auf den entsprechenden Ordner definitiv Schreibrechte.
Es macht aber z.B. einen Unterschied, ob ich "Webseite, komplett" oder "Webseite, nur HTML" speichere. Diesen Thread hier z.B. kann nicht als "Webseite, komplett" speichern, dann kommt fehlgeschlagen. Ändere ich es beim Speichern hingegen auf "Webseite, nur HTML" und ändere sonst nichts, dann klappt es.
Man kann jetzt durchaus darüber diskutieren ob Firefox nicht bessere
Fehlermeldungen anzeigen kann.
Berechtigter Vorwurf. Nur einen winzigen orangen Punkt zu setzen und die
Speicherung nicht durchzuführen ist nicht so der Hit. Eine Warnmeldung
(Speichern nicht möglich, weil...) wäre sicher zielführender.
Es liegt bei aktueller Software voll und ganz im Trend, Fehlermeldungen so weit wie möglich zu verstecken, und wenn man sie denn doch unbedingt anzeigen muss, dann auf gar keinen Fall zu verraten, was denn der konkrete Fehler war.
Es macht aber z.B. einen Unterschied, ob ich "Webseite, komplett" oder
"Webseite, nur HTML" speichere. Diesen Thread hier z.B. kann nicht als
"Webseite, komplett" speichern, dann kommt fehlgeschlagen.
Das ist bei mir auch so. Wenn ich dann auf den wiederholen-Button klicke, scheint es aber zu gehen, inklusive den ganzen referenzierten Dateien. Diese werden dann aber beim Anzeigen der Seite trotzdem nicht gefunden.
Also ich kann im Firefox unter Ubuntu nur "Seite speichern unter..."
anwählen. Dann wird die komplette Seite abgespeichert.
Bei mir kommt dann ein Datei-Auswahldialog mit einer Combo-Box, wo ich verschiedene Optionen wählen kann. Fehlt das bei dir?
Und was ist der Unterschied zwischen komplett und HTML?
HTML ist nur die reine html-Datei. Komplett ist mit allen referenzierten Dateien wie z.B. Bilder. Die werden dann auch alle mit runtergeladen und in einem Unterverzeichnis gespeichert. Die würden ja fehlen, wenn du nur die html-Seite selbst runterlädst.
Meiner Erfahrung nach ist snap so ein komisches Ubuntu-Ding, was gerne mal Ärger macht. Unter Ubuntu ist firefox aber immer als snap installiert. Wenn du es per apt installierst, wird dir trotzdem das snap untergeschoben.
Also ich kann im Firefox unter Ubuntu nur "Seite speichern unter..."
anwählen. Dann wird die komplette Seite abgespeichert.
Unten ist ein Dropdown versteckt, sh. screenshot.
Und was ist der Unterschied zwischen komplett und HTML?
Bei komplett versucht Firefox alle verlinkten Bilddateien, CSS, JS, usw. zu identifizieren und läd die in einen Unterordner neben die HTML-Datei herunter. Die Links im HTML werden dementsprechend angepasst. Funktioniert nicht gut, wenn die HTML-Seite Content dynamisch (z.B. per JS-Generierter URL) nachladen will.
Seite als PDF speichern ist meist die bessere Option.
Und was ist "als Snap installiert" schon wieder?
Ubuntu-Krankheit. Da wird der Firefox (ähnlich wie z.B. bei Docker) in einer separaten Betriebssystem-Umgebung installiert, und hat aus dieser heraus nicht mehr auf alle Ordner des "Haupt-Betriebsystems" außen Zugriff. z.B. ein Download nach /tmp ist nachher plötzlich "woanders" unauffindbar.
Geh mal ins Software-Center von Ubuntu und aktualisiere Firefox. Habe mal testweise Ubuntu 22.04 in einer VM installiert und konnte den Fehler reproduzieren. Nach dem Update von 99.0.1 auf 115.0.2 war der Fehler verschwunden. Firefox entfernt dann alle unzulässigen Zeichen aus dem Dateinamen. Mit Snap, wie erst gedacht, hat das nichts zu tun und auch das Speichern auf einen USB-Stick war möglich.
Wenn ich dann auf den wiederholen-Button
klicke, scheint es aber zu gehen, inklusive den ganzen referenzierten
Dateien. Diese werden dann aber beim Anzeigen der Seite trotzdem nicht
gefunden.
Unter Debian macht der FF das bei mir auch.
Oft kommt beim ersten Versuch der orangene Punkt, ein erneutes herunterladen schlaegt danach aber nie fehl.
Ist mir auch bis jetzt auch noch nicht aufgefallen, dass sich die so lokal abgespeicherte Seite dann doch nicht vollstaendig anzeigen laesst.
Bei mir kommt dann ein Datei-Auswahldialog mit einer Combo-Box, wo ich
verschiedene Optionen wählen kann. Fehlt das bei dir?
Nö, fehlt nicht, denn ich hatte die Option bereits im Datei-Menü erwartet. Im Datei-Auswahldialog ist mir die Option bisher noch nicht aufgefallen. Bisher bestand auch noch nie die Notwendigkeit, eine Seite ohne die zugehörigen Inhalte abzuspeichern.
Ein früherer Browser bot die Option, eine Seite komplett in einer Datei abzuspeichern. Das fand ich gut, denn unter Windows werden die beiden erzeugten Dateien (HTML+Ordner) mal zusammen und mal nicht zusammen verwaltet. Diese Option boten nachfolgende Browser leider nicht mehr an.
Das spricht dann nicht für Firefox, denn der sollte Sonderzeichen in
Dateinamen sinnvoll "Escapen" bzw. ersetzen.
Eben mal den Firefox unter Windows getestet, hier wird der senkrechte
Strich durch einen Unterstrich ersetzt:
Also statt "Beschreibung | eBay.html" unter Ubuntu
heißt das: "Beschreibung _ eBay.html" unter Windows
Wenn das so ist (ich habe es nicht ausprobiert, halte es aber für durchaus möglich bis sogar sehr wahrscheinlich), dann ist Firefox defekt. Das darf die Ersetzung natürlich nicht von dem OS abhängig machen, unter dem es läuft, sondern muß sie von den Restriktionen des Ziel-Dateisystems abhängig machen.
Denn: die FS-Treiber des OS berücksichtigen sie ja offensichtlich korrekt. Genau das führt ja zum Fehler...
Manche Leute erwarten das rundum-glücklich Paket, wie Microsoft es einem anzubieten versucht. Das führt zu anderen Probleme, zum Beispiel zu tief ins System verankerte Tools, die man nicht austauschen kann.
Manche Leute erwarten das rundum-glücklich Paket, wie Microsoft es einem
anzubieten versucht. Das führt zu anderen Probleme, zum Beispiel zu tief
ins System verankerte Tools, die man nicht austauschen kann.
Du hast wohl nicht verstanden, dass das Problem hier nicht unter Windows auftritt, sondern unter Linux. Und es ist definitiv ein Bug.
Man kann allenfalls darüber streiten, ob es ein Bug in Firefox oder dem zuständigen FS-Treiber von Linux ist.
Man kann allenfalls darüber streiten, ob es ein Bug in Firefox oder dem
zuständigen FS-Treiber von Linux ist.
Man kann auch sagen, dass es ein Bug in der exFAT-Spezifikation ist. Dann wäre Microsoft wieder schuld, und die sind ja sowieso die Bösen.
Der Linux-Treiber versucht diese Bösartigkeit weitestmöglich zu kaschieren, schafft es aber nicht zu 100%, und darüber stolpert Firefox.
Oder man akzeptiert einfach, dass Fremd-Dateisysteme immer ein Kompromiss bleiben, und man eben mit ein paar Reibungspunkten leben muss.
Ist auch nicht anders, wenn du unter Windows per IFS ein EXT4-Dateisystem einbindest.
Man kann auch sagen, dass es ein Bug in der exFAT-Spezifikation ist.
Wieso? Da steht doch absolut eindeutig drin, welche Zeichen nicht erlaubt sind.
Der Linux-Treiber versucht diese Bösartigkeit weitestmöglich zu
kaschieren, schafft es aber nicht zu 100%, und darüber stolpert Firefox.
Also ich habe das nicht umfassend ausprobiert, aber ich würde mal sagen, dass der exFAT-Treiber eigentlich nichts kaschiert. Wie es auch schon die FAT-Treiber gehandhabt haben und bis heute handhaben. Was illegal ist, wird bei Create abgelehnt und fertig isses.
Oder man akzeptiert einfach, dass Fremd-Dateisysteme immer ein
Kompromiss bleiben, und man eben mit ein paar Reibungspunkten leben
muss.
Ganz genau. Das führt eben in der Konsequenz dazu, dass sich die Anwendung um diese Probleme zu kümmern hat. Also haben wir hier ein Bug in Firefox.
Ist auch nicht anders, wenn du unter Windows per IFS ein
EXT4-Dateisystem einbindest.
Der Linux-Treiber versucht diese Bösartigkeit weitestmöglich zu
kaschieren, schafft es aber nicht zu 100%, und darüber stolpert Firefox.
Also ich habe das nicht umfassend ausprobiert, aber ich würde mal sagen,
dass der exFAT-Treiber eigentlich nichts kaschiert.
Das sehe ich auch so. Er lässt halt zu, was das Dateisystem zulässt und alles andere nicht.
Oder man akzeptiert einfach, dass Fremd-Dateisysteme immer ein
Kompromiss bleiben, und man eben mit ein paar Reibungspunkten leben
muss.
Ganz genau. Das führt eben in der Konsequenz dazu, dass sich die
Anwendung um diese Probleme zu kümmern hat. Also haben wir hier ein Bug
in Firefox.
Das sehe ich dagegen nicht so. Der Nutzer will eine Webseite abspeichern, deren Name Zeichen enthält, die das Dateisystem nicht kann. Warum ist das die Schuld von Firefox? Warum sollte es dessen Aufgabe sein, die Datei implizit - quasi hinter dem Rücken des Benutzers - umzubenennen, um diese Einschränkung zu umgehen? Wo ist überhaupt spezifiziert, durch was die vom Dateisystem nicht akzeptierten Zeichen zu ersetzen sind?
Das sehe ich höchstens als Komfort-Feature. Wenn dieses nicht da ist, ist das aber kein Bug.
Ist auch nicht anders, wenn du unter Windows per IFS ein
EXT4-Dateisystem einbindest.
Natürlich. Exakt dieselbe Problematik.
Nicht ganz, denn es gibt keine Zeichen, die die Windows-üblichen Dateisysteme können, ext4 aber nicht.
Den Bug hatte ich auch öfters, kurioserweise immer nur beim ersten Versuch zu Speichern. Wenn dann rechts oben das fehlgeschlagen Icon kam und ich auf nochmal versuchen geklickt habe ging es auf einmal. o.O
Man kann beim Speichern immer noch alle in Linux legalen
Dateinamensbestandteile eingeben.
Es gibt keine "unter Linux legalen Dateinamensbestandteile". Es hängt auch unter Linux immer vom Filesystem ab. Und die haben nunmal diesbezüglich unterschiedliche Fähigkeiten. Es gibt in jedem Filesystem für Datei-/Verzeichnisnamen illegale Zeichen. Es sind nur halt nicht überall dieselben.
Da kannst du aufstampfen und die Luft anhalten, bis du blau anläufst, das wird nichts an diesem Sachverhalt ändern.
Sie haben allenfalls angepasst/angeglichen, wie der Dateinamen
Vorschlag aus dem html-<title> erzeugt wird.
Das ist doch gut. Man kann den sinnvollen Vorschlag annehmen, man kann aber auch was eigenes Sinnvolles eingeben.
Und die Hardcore-Fußaufstampfer können sogar was Sinnloses eingeben, wenn sie unbedingt wollen. Der FS-Treiber bremst sie dann halt ggf. aus.
Das ist das absolute Minimum, wo man davon ausgehen darf, dass sie überall erlaubt sind. Sind aber nicht einmal Abstände dabei.
Oh, und . und .. kann man die Dateien natürlich auch nicht nennen, aber das haben sie dort vergessen zu erwähnen.
Und die haben nunmal
diesbezüglich unterschiedliche Fähigkeiten. Es gibt in jedem
Filesystem für Datei-/Verzeichnisnamen illegale Zeichen. Es sind nur
halt nicht überall dieselben.
In ext4 sind Dateinamen binär / Kodierungslos gespeichert. Am besten geht man beim Anzeigen einfach davon aus, dass sie in UTF-8 sind, aber wenn mit ihnen arbeitet, sollte man sie als Binär betrachten. Ok, man kann auch andere locale beim System setzten, aber heutzutage würde ich das nicht mehr empfehlen. Die einzigen Bytes, die nicht erlaubt sind, sind 0x2f also '/' und 0x00. (Aufgrund dessen wie UTF-8 kodiert ist, tauchen 0x2f und 0x00 nie in Codepoints auf, die mehrere Bytes zur Kodierung brauchen).
Das ist bei den meisten Dateisystemen, die aus der UNIX Welt kommen, so.
In neueren Linux Versionen bei ext4 hat man zwar noch die "casefold" Option. Beim Erstellen und Auflisten von Dateinamen ändert sich dort nichts, aber beim öffnen hat der Kernel eine normalisierte interne Version der Dateinamen, die er vergleicht, um so identische Dateinamen mit unterschiedlicher Gross/Klein Schreibung oder nicht normalisierte Dateinamen machten zu können: https://www.kernel.org/doc/html/latest/admin-guide/ext4.html#case-insensitive-file-name-lookups Aber von der Option werde ich definitiv die Finger lassen.
Und das mit dem nicht erlauben von '/' und 0x00, ist wie das imt den '.' und ist '..' Dateien, eigentlich auch eher eine Limitation des OS, als des Dateisystems. Technisch gesehen, wenn man rein nur das Dateisystem betrachtet, gibt es dort dann eigentlich gar keine illegale Zeichen mehr. Aber es gibt auch keine OSe und keine Tools, die die akzeptieren, aus der Sicht könnte man natürlich schon argumentieren, es wäre teil des Dateisystems.
Jedenfalls, Dateisysteme mit solchen irrwitzigen Dateinamen Limitationen, kommen meistens aus der DOS/NT/Windows Welt. Und da ist es auch hauptsächlich das FAT / ExFAT Zeugs. Wenn man z.B. NTFS anschaut, ist es eigentlich gar nicht mehr so schlimm. Man könnte gleiche Dateien mit unterschiedlicher Gross Kleinschreibung haben. Dateinamen wie NUL und anderen Kram gehen eigentlich auch. Ist dann halt ein Krampf unter Windows auf die zuzugreifen, mit seinen UNC Pfaden und Rückwärtsorientierung.
Als Dateisystem für USB-Sticks, die sowohl unter Windows als auch unter Linux verwendet werden, würde ich UDF, Version 2.01 empfehlen. Dort kann man, laut Wikipedia, jedes UTF-16 Zeichen ausser U+FEFF und U+FFFE nehmen.
Als Dateisystem für USB-Sticks, die sowohl unter Windows als auch unter
Linux verwendet werden, würde ich UDF, Version 2.01 empfehlen. Dort kann
man, laut Wikipedia, jedes UTF-16 Zeichen ausser U+FEFF und U+FFFE
nehmen.
Aber als Linux Nutzer ist es mir eigentlich egal, wenn Windows Nutzer mit Windows Probleme haben.
Wobei das nicht unbedingt auch für alle Anwendungen gelten muss (explorer.exe mit eingenommen), und man für manche Sachen eventuell UNC Pfade braucht. Aber zumindest theoretisch könnte Windows damit umgehen.
Ganz genau. Das führt eben in der Konsequenz dazu, dass sich die
Anwendung um diese Probleme zu kümmern hat. Also haben wir hier ein Bug
in Firefox.
Das sehe ich dagegen nicht so. Der Nutzer will eine Webseite
abspeichern, deren Name Zeichen enthält, die das Dateisystem nicht kann.
Warum ist das die Schuld von Firefox? Warum sollte es dessen Aufgabe
sein, die Datei implizit - quasi hinter dem Rücken des Benutzers -
umzubenennen, um diese Einschränkung zu umgehen? Wo ist überhaupt
spezifiziert, durch was die vom Dateisystem nicht akzeptierten Zeichen
zu ersetzen sind?
Das sehe ich höchstens als Komfort-Feature. Wenn dieses nicht da ist,
ist das aber kein Bug.
Unser C-hater hat noch nie begriffen, was der Unterschied zwischen einem Bug und einem fehlenden Feature ist. Hat er schon immer gezeigt, und hier wieder.
Es gehört also nicht zur Aufgabe eines 0815-Programms, sämtliche Eigenschaften sämtlicher Dateisysteme, die man in Linux einbinden könnte, zu kennen. Soll es auch nicht, denn das ist schließlich der Sinn von Abstraktionsebenen und vereinheitlichten APIs, damit Anwendungen sich nicht mehr um solchen Spezialkram bei Standard-Operationen kümmern müssen (bei NFS als Beispiel hätte eine Anwendung ohnehin kaum noch eine Chance, sowas zu erkennen). Das kann man machen, wenn solche Dateioperationen kritisch für die Anwendungen sind, dann haben die idR. aber auch ein ausgefeilteres Error-Handling, bzw. es wird vorher definiert, welche Dateisysteme überhaupt supported werden (bei Datenbanken z.B.). Aber bei solchen 0815-Anwendungen reicht es, wenn der Fehler wenigstens so behandelt wird, daß der Anwender ihn auch inkl. RC erkennen und drauf reagieren kann. Wenn FF illegale Zeichen entfernen/ersetzen würde, dann wäre das ein nettes Feature, aber eben gewiss kein Bug, wenn dem nicht so wäre.
Ich betrachte eher den Trend, Fehler, Fortschrittsbalken u.a. Dinge möglichst zu verstecken oder unauffällig zu machen, als (Design-) Bug ...
Als Dateisystem für USB-Sticks, die sowohl unter Windows als auch unter
Linux verwendet werden, würde ich UDF, Version 2.01 empfehlen. Dort kann
man, laut Wikipedia, jedes UTF-16 Zeichen ausser U+FEFF und U+FFFE
nehmen.
Mit Sicherheit nicht. Daß ein Dateisystem praktisch alles akzeptiert, heist noch lange nicht, daß das OS oder die Tools dies auch ausschöpfen kann/können. Denn Zeichen, die eine Sonderfunktion haben, werden gern auf höherer Eben abgewiesen bzw. in ihrer Sonderfunktion genutzt (manches läßt sich mit Escape-ereien noch hintricksen).
Aber als Linux Nutzer ist es mir eigentlich egal, wenn Windows Nutzer
mit Windows Probleme haben.
Tja, ich bin sowohl Linux-Nutzer als auch Windows-Nutzer (und nicht nur Nutzer, sondern auch Entwickler für beide Zielsysteme). Und deswegen sind für mich jederzeit die Probleme beider Seiten relevant.
Du hingegen bist wohl nur so ein strohdummer Fanboy.
Wobei das nicht unbedingt auch für alle Anwendungen gelten muss
(explorer.exe mit eingenommen), und man für manche Sachen eventuell UNC
Pfade braucht. Aber zumindest theoretisch könnte Windows damit umgehen.
Nein. Das NT-API könnte das, nicht aber Win32. Das sind zwei ganz klar voneinander abgegrenzte APIs. UNC-Pfade stellen auch nur eine Submenge des über das NT-API möglichen im Win32-Space bereit. Das ist alles.
Das NT-API ist übrigens vom Konzept her sehr "unixoid". Wohl deswegen wollte man es weder den Anwendern noch den Programmierern ernsthaft zumuten und hat sich zu der Win32-Zwischenschicht durchgerungen. Aber natürlich hat bei dieser Entscheidung auch die Notwendigkeit der Integration der DOS-basierten Altlasten eine erhebliche Rolle gespielt.
So ist es halt in der Software-Entwicklung: Wenn jederzeit alle zukünftigen Anforderungen bereits bekannt wären, würde man die perfekte Software entwickeln können. Allerdings würde dann wohl auch niemals irgendwas fertig werden...
Fehl.png
(5,3 KB)
