Firefox unter Ubuntu: Webseite speichern fehlgeschlagen

[Hans H. (wen_h)]

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

[Kaj G. (Firma: RUB) (bloody)]

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.

[Mario M. (thelonging)]

Wahrscheinlich ist der Firefox als Snap installiert.
https://bugzilla.mozilla.org/show_bug.cgi?id=1766196

[Hans H. (wen_h)]

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.

[C-hater (c-hater)]

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.

[Harald K. (kirnbichler)]

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.

[Εrnst B. (ernst)]

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?

[Harald K. (kirnbichler)]

Ε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.

[Hans H. (wen_h)]

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

[Εrnst B. (ernst)]

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.

[Harald K. (kirnbichler)]

Ε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?

[Εrnst B. (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?

[Rolf M. (rmagnus)]

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?

[Harald K. (kirnbichler)]

Ε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.

[Rolf M. (rmagnus)]

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.

[Harald K. (kirnbichler)]

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?

[Malte _. (malte)]

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?

[Rolf M. (rmagnus)]

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.

[Günter L. (Firma: Privat) (guenter_l)]

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.

[Ein T. (ein_typ)]

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

[Hans H. (wen_h)]

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.

[Joachim S. (oyo)]

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.

[Rolf M. (rmagnus)]

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.

[Hans H. (wen_h)]

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?

[Rolf M. (rmagnus)]

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.

[Εrnst B. (ernst)]

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.

[Mario M. (thelonging)]

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.

[Stefan F. (Gast)]

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.

[Johannes U. (kampfradler)]

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.

[Hans H. (wen_h)]

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.

[C-hater (c-hater)]

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...

[Εrnst B. (ernst)]

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.

[Stefan F. (Gast)]

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.

[C-hater (c-hater)]

Ε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...

[C-hater (c-hater)]

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.

[Εrnst B. (ernst)]

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.

[C-hater (c-hater)]

Ε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.

[Mario M. (thelonging)]

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.

[C-hater (c-hater)]

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...

[Εrnst B. (ernst)]

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.

[Rolf M. (rmagnus)]

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.

[Rolf M. (rmagnus)]

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.

[Flo (linux_user)]

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

[C-hater (c-hater)]

Ε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.

[Daniel A. (daniel-a)]

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.

[Rolf M. (rmagnus)]

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?

[Daniel A. (daniel-a)]

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.

[Jens G. (jensig)]

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 
...

[Jens G. (jensig)]

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).

[C-hater (c-hater)]

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...