Hallo, 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? Hans
:
Bearbeitet durch User
Das kann z.B. passieren, wenn Firefox keine schreibrechte für den Ordner hat, in den du speichern willst. Oder die Partition ist voll, etc.
:
Bearbeitet durch User
Wahrscheinlich ist der Firefox als Snap installiert. https://bugzilla.mozilla.org/show_bug.cgi?id=1766196
:
Bearbeitet durch User
Vielen Dank für den Hinweis! 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.
Hans H. schrieb: > 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. Verboten sind: " \ / < > | : * ? Ich hoffe, ich habe nichts vergessen.
Hans H. schrieb: > 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.
Harald K. schrieb: > 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?
Εrnst B. schrieb: > 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.
Harald K. schrieb: > 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
Harald K. schrieb: > 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.
Εrnst B. schrieb: > 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?
Harald K. schrieb: > Meinst Du das wirklich ernst? Ja. Versuch mal auf deinem exFAT-Stick ein mkdir hallo mv hallo Hallo Ist das jetzt ein Fehler vom "mv"-Utility oder eine Einschränkung vom Dateisystem?
Harald K. schrieb: > 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. Harald K. schrieb: > 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. Harald K. schrieb: > Εrnst B. schrieb: >> 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?
:
Bearbeitet durch User
Εrnst B. schrieb: > 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.
Harald K. schrieb: > 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.
:
Bearbeitet durch User
Nach Deiner Sichtweise ist es also ein Fehler von Linux, andere als linux-native Dateisysteme zu unterstützen. Warum aber gibt Ubuntu vor, andere Dateisysteme zu unterstützen?
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? 1. Nur Dateinamen akzeptieren die überall gehen -> 8.3 Zeichenlimit. Aber das will außer DOS Nutzern doch niemand mehr. 2. 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?
Harald K. schrieb: > Nach Deiner Sichtweise ist es also ein Fehler von Linux, andere als > linux-native Dateisysteme zu unterstützen. Nein. Wieder bist du derjenige, der sowas schreibt: Rolf M. schrieb: > Harald K. schrieb: >> 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.
:
Bearbeitet durch User
von Hans H. scvhrieb: >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.
Hans H. schrieb: > 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. man 1 detox
Günter L. schrieb: > 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? Malte _. schrieb: > 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.
Hans H. schrieb: > Malte _. schrieb: >> 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. Joachim S. schrieb: > 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.
Joachim S. schrieb: > Es macht aber z.B. einen Unterschied, ob ich "Webseite, komplett" oder > "Webseite, nur HTML" speichere. Also ich kann im Firefox unter Ubuntu nur "Seite speichern unter..." anwählen. Dann wird die komplette Seite abgespeichert. Und was ist der Unterschied zwischen komplett und HTML? Und was ist "als Snap installiert" schon wieder?
Hans H. schrieb: > 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. > Und was ist "als Snap installiert" schon wieder? https://wiki.ubuntuusers.de/snap/ 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.
:
Bearbeitet durch User
Hans H. schrieb: > 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.
Rolf M. schrieb: > Es liegt bei aktueller Software voll und ganz im Trend, Das bin ich seit Windows 3 so gewohnt. Ich bin froh, das nur wenige Linux Entwickler diesem Vorbild folgen.
Rolf M. schrieb: > 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.
Rolf M. schrieb: > 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.
Hans H. schrieb: > Harald K. schrieb: >> 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...
C-hater schrieb: > sondern muß sie von den Restriktionen des > Ziel-Dateisystems abhängig machen. ... blatant layering violation ... Details, welches Dateisystem wohin gemountet ist, sollten Anwendungen nichts angehen.
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.
Εrnst B. schrieb: > C-hater schrieb: >> sondern muß sie von den Restriktionen des >> Ziel-Dateisystems abhängig machen. > > ... blatant layering violation ... > > Details, welches Dateisystem wohin gemountet ist, sollten Anwendungen > nichts angehen. Das wäre ein Ansatz in einer Welt, in der alle Filesystem gleich sind. So eine Welt haben wir aber nicht. Zum Glück, möchte man sagen...
Stefan F. schrieb: > 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.
C-hater schrieb: > 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.
Εrnst B. schrieb: > 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. Natürlich. Exakt dieselbe Problematik.
C-hater schrieb: > Also haben wir hier ein Bug in Firefox. Mario M. schrieb: > Nach dem Update von 99.0.1 auf 115.0.2 war der Fehler verschwunden.
Mario M. schrieb: > C-hater schrieb: >> Also haben wir hier ein Bug in Firefox. > > Mario M. schrieb: >> Nach dem Update von 99.0.1 auf 115.0.2 war der Fehler verschwunden. LOL. Hat wohl irgendwer bei den Firefox-Entwicklern ähnlich eingeschätzt wie ich...
C-hater schrieb: > Mario M. schrieb: >> C-hater schrieb: >>> Also haben wir hier ein Bug in Firefox. >> >> Mario M. schrieb: >>> Nach dem Update von 99.0.1 auf 115.0.2 war der Fehler verschwunden. > > LOL. Hat wohl irgendwer bei den Firefox-Entwicklern ähnlich eingeschätzt > wie ich... Nö. Man kann beim Speichern immer noch alle in Linux legalen Dateinamensbestandteile eingeben. Firefox hat sich also dem Microsoft-Diktat nicht gebeugt. Sie haben allenfalls angepasst/angeglichen, wie der Dateinamen Vorschlag aus dem html-<title> erzeugt wird.
Hans H. schrieb: > Ein früherer Browser bot die Option, eine Seite komplett in einer Datei > abzuspeichern. Das ist dann allerdings kein Standardformat mehr, sondern proprietär.
C-hater schrieb: >> 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
Εrnst B. schrieb: > 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. Genau so sollte es sein.
C-hater schrieb: > Εrnst B. schrieb: > >> 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. Man könnte hier den POSIX Standart zurate ziehen. https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap04.html#tag_04_07 Unter "4.7 Filename Portability". Sollte nicht mit - anfangen. Abgesehen davon darf man die Zeichen nehmen unter https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap03.html#tag_03_276 "3.276 Portable Filename Character Set". Das sind: a-z A-Z . _ - 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.
:
Bearbeitet durch User
Daniel A. schrieb: > Oh, und . und .. kann man die Dateien natürlich auch nicht nennen, aber > das haben sie dort vergessen zu erwähnen. Der Teil behandelt ja auch nur das Character Set, keine reservierten Namen. Daniel A. schrieb: > 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 kann Windows dann auch damit umgehen?
Ja aber klar doch! * 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.
Rolf M. schrieb: >> 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 ...
Rolf M. schrieb: > Daniel A. schrieb: >> 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 kann Windows dann auch damit umgehen? Daniel A. schrieb: > Ja aber klar doch! * 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).
Daniel A. schrieb: > 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...
Bitte 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.