@ReneUX Ja, aber wo ist jetzt ein Bug?

→ Stimmt, ist eher kein Bug, nur ein Anwendungsfehler seitens des Anwenders :-)
Sorry für alle unnötig gebundenen Kapazitäten.

Wieso ein Bug? : “Die Dateinamen werden für jedes Betriebssystem passend aufbereitet.”

In Windows sind sie nicht erlaubt, da “filtert” sie MV ganz ohne Ersetzungstabelle.

In Linux sind sie nicht verboten (mit ext4 gehts ja), daher filtert sie MV dort nicht.

Beim macOS ähnlich.

Insofern passt die Aussage “jedes Betriebssystem passend” doch eh, oder?

Problematisch ist die Kombi Linux und FAT32, und letzteres ist wohl kein typisches Linuxfilesystem. Und selbst da stellt MV mit der Ersetzungstabelle ein passendes Werkzeug zur Verfügung.

Ich würde ja eher dazu neigen, dass das Job des OS/des Filesystemtreibers wäre, sich darum zu kümmern, ob Filenamen zum verwendeten Filesystem passen.

Das tut es wohl und “findet” diesen “unerlaubte” Zeichen enthaltenden Dateinamen nicht und reicht den Fehler an MediathekView durch. Das Problem tritt (dann wohl korrekterweise) aber auch in anderen Anwendungen auf: Mittels Krusader (einem Dateimanager) “…”-kritische Datei vom EXT4 auf FAT32 kopieren → Krusader meldet dann « “…” konnte nicht geschrieben werden ».
Per Copy&Paste in PCManFM (anderer Dateimanager) EXT›FAT-kopieren bringt dann erst die korrekt-aussagekräftige Meldung « ungültiger Dateiname ».

Würde sich jetzt Mediathekview per Default d’rum kümmern,

Ich würde ja eher dazu neigen, dass das Job des OS/des Filesystemtreibers wäre, sich darum zu kümmern, ob Filenamen zum verwendeten Filesystem passen.

Ich mein, von jedem Anwendungsprogramm zu verlangen, die Besonderheiten aller möglichen Filesysteme richtig zu handeln, die ein User einsetzen könnte, erscheint mir doch etwas Zuviel des Guten.

In diesem Sinne, hat MV m.E. eh dem User das richtige Werkzeug gegeben: Die Ersetzungstabelle.

Mac-Nutzer könnten noch testen, wenn denn sichergestellt ist, dass nicht die Ersetzungstabelle das " schon wegfiltert, welches Zeichen denn dann im Endergebnis an Stelle des " auf dem FAT32-Datenträger auftaucht, und evtl. auch mal vergleichen, welches, wenn so ein “unter Windows “böser”” Dateiname außerhalb von Mediathekview auf’s FAT32 geschubst wird.

Edit: ein “davor” eingefügt,
@MenchenSued
Unter Windows hatte ich glaub’ ich auch das " in der Tabelle, und wohl beim Linux-Umstieg gepennt, nur um dann eben früher oder später (jetzt) dieses unkritische Problemchen zu kriegen.

Könnte aber auch an der Dateigrösse liegen, FAT32 kann, wimre, nur Dateien bis etwa 4 GB verwalten.

@ReneUX sagte: Es scheint wirklich an dem FAT32 als Ziel zu liegen

Hab das eben mit der Folge 20 von “Bon Courage” unter macOS getestet: Hier zumindest tritt das Problem bzw. die Fehlermeldung beim Speichern auf einen FAT32-formatierten USB-Stick nicht auf.

Das müsste also noch jemand unter Linux reproduzieren.