MV13.3.0: Speichern unter Linux

[kklaffki]

Hallo, seltsamerweise kann ich keine Filme speichern wenn der Pfad (Linux) ein symbolischer Link ist; “Pfad ist nicht beschreibbar” wird mir dann gemeldet. Starte ich den MV13.2.x tritt das Problem nicht auf. Gehe ich nicht über den symb. Link sondern direkt auf den Ordner, wird auch in MV13.3.0 gespeichert.
Ich verwende die V11 von OpenJRE.
Gruß,
Kirsten

[Ein ehemaliger Benutzer]

@kklaffki erinnert mich ein klein wenig an das Problem, das ich mit 13.3.0 mit Netzwerkpfaden hatte. Gibt hier nen thread dazu. https://forum.mediathekview.de/topic/2608/netzlaufwerk-als-zielpfad-geht-nicht-mehr
Versuche mal, ob bei den nightly builds das Problem noch besteht. Die haben von 13.3.0 auf “13.4.0pre” in diesem Bereich eine Veränderung im Quellcode erhalten. Die Veränderung betrifft einen Bug in Java im Zusammenhang mit Programmierbibliotheken zu Dateizugriffen.

In 13.2.1 war die fehlerhafte Bibliothek noch nicht verwendet. Ich weiß aber nicht auswendig, ob die Änderung von 13.3.0 auf 13.4.0pre ggfs. ausdrücklich prüft, ob das Programm im Moment unter Windows läuft.

Was Du noch machen kannst: schau mal, ob Du eine Mehrfachfachauswahl in dieses per sym link verwiesene Verzeichnis speicher kannst (ist z.B. in o.g. thread beschrieben)

Ggfs. finde ich ab nächster Woche mal Zeit, mir das anzuschauen.

[kklaffki]

@rubikon Danke für die schnelle Antwort! Ich teste mal die nightly builds.
Ja, mein Problem mit den Symlinks hat die gleichen Erscheinungen wie in dem Von Dir genannten thread.

[kklaffki]

@rubikon nightly build 13.5.0 ändert leider nix! Es kommt die gleiche Fehlermeldung, der Pfad sei nicht schreibbar

[DerReisende77]

@kklaffki ist auch logisch weil ich mir das noch nicht angesehen habe da ich unterwegs bin.
Welches Linux verwendest du denn?

[MenchenSued]

@DerReisende77
Es sieht so aus, als würde das Problem nur bestehen, wenn der symbolische Link ganz am Ende steht. Ich habe beispielsweise einen Pfad /home/user/data/Videos/Neu, wobei data auf eine eigene Partition verweist. Hierbei gibt es unter 13.3.0 keine Probleme.
Bei /home/user/data/Videos/Neulink (Neulink verweist auf ./Neu) gibt es die Fehlermeldung “Pfad nicht beschreibbar”.
Bei /home/user/data/Videos/Neulink/Ablage gibt es ebenfalls keine Probleme, obwohl zwei Links enthalten sind, der Ordner “Ablage” aber existiert. (Ubuntu 16.04 LTS)

[DerReisende77]

@MenchenSued Ich habe gerade eine Änderung in den develop branch eingebracht. Dieser sollte das Problem beheben. Falls es zu einem Fehler kommt, wird dieser in mediathekview.log (hoffentlich) als Fehler am Ende protokolliert von einer Funktion “checkPathWritable()”.
Könntest Du das evtl bei dir testen ob es funktioniert?

[Ein ehemaliger Benutzer]

Kurzfassung: Abhilfe mit 13.3 unter Linux scheint zu klappen:
Mehrere Filme mit STRG/CTRL auswählen und dann mit Taste D den Download starten.
Aber ich hab die Stelle eingegrenzt, an welcher das Problem entsteht. siehe weiter im Text

Ich möcht mich aber nicht einmischen in Form eines Vorschlags für einen workaround.

In einer Linux VM (Debian Testing) habe ich mir eben AdoptOpenJDK11 und MV13.3.0 (Linux) eingespielt.
Mit dem Befehl
jdk-11/bin/java -jar MediathekView-latest-linux/MediathekView.jar
habe ich MV gestartet.

Dann habe ich mir in
/home/rubikon/Videos
ein Verzeichnis /Neu angelegt
und per ln -s Neu/ Neulink einen symlink namens Neulink auf Neu (um auf MuenchenSued’s Struktur zurückzugreifen)

Ich kann mit diesem setting Videos nach /home/rubikon/Videos/Neu abspeichern
und ich erhalte eine Fehlermeldung “Pfad nicht beschreibbar” beim Verlassen des Speicher-Dialogs, wenn ich als Ziel /home/rubikon/Videos/Neulink angebe

Damit kann ich schon mal bestätigen: Problem reproduzierbar.

Ich hab mal ein wenig gespielt. Und es liegt in dem von MuenchenSued beschriebenen Szenario NICHT an dem Java-Bug bzgl. Files.isWritable()

Ich hab noch mehr gespielt und gesehen, dass der Aufruf
Files.createDirectories(path);
eine Exception wirft.
java.nio.file.FileAlreadyExistsException: /home/rubikon/Videos/Neulink
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:94)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:385)
at java.base/java.nio.file.Files.createDirectory(Files.java:689)
at java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:796)
at java.base/java.nio.file.Files.createDirectories(Files.java:742)

Nach dieser Exception kehrt die Funktion GuiFunktionenProgramme.checkPathWriteable()
mit false zurück - was wiederum die Meldung “Pfad nicht beschreibbar” bewirkt.

Ich hoffe das hilft weiter bzw. bei Bedarf einfach Fragen stellen

edit:
final boolean isWritable = Files.isWritable(path);
final boolean isCanWrite = path.toFile().canWrite();

liefern sowohl bei Pfad /home/rubikon/Videos/Neu als auch bei Pfad /home/rubikon/Videos/Neulink beide true
Das ist imo schon mal gut.

[Ein ehemaliger Benutzer]

@DerReisende77

Ich hab mit dem Verfassen meines Posts vorhin so lange gebraucht, dass ich Deines zuerst übersehen hatte. War ggfs. zeitlich nah beieinander. Ich hab jedenfalls nochmal git pull gemacht und in MV13.3 die Wesentlichen Zeilen (LinkOption.NOFOLLOW_LINKS und logging) eingebaut. Zeilennummer in checkPathWriteable stimmt daher nicht ganz mit Deiner Datei zusammen… aber es kommt auch hier zu der exception (wie o.g. wirft bereits das Files.createDirectories(path); die Exception, also die Zeile vor der geänderten Zeile (Files.isDirectory(path, LinkOption.NOFOLLOW_LINKS))

[ERROR] 2019-09-02 20:35:29.558 [AWT-EventQueue-0] mediathek.tool.GuiFunktionenProgramme - checkPathWritable()
java.nio.file.FileAlreadyExistsException: /home/rubikon/Videos/Neulink
at sun.nio.fs.UnixException.translateToIOException(UnixException.java:94) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111) ~[?:?]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116) ~[?:?]
at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:385) ~[?:?]
at java.nio.file.Files.createDirectory(Files.java:689) ~[?:?]
at java.nio.file.Files.createAndCheckIsDirectory(Files.java:796) ~[?:?]
at java.nio.file.Files.createDirectories(Files.java:742) ~[?:?]
at mediathek.tool.GuiFunktionenProgramme.checkPathWriteable(GuiFunktionenProgramme.java:370) ~[MediathekView.jar:?]

[Ein ehemaliger Benutzer]

Scheint’s ist das Phänomen seit Juli 2015 als Problem gemeldet, für Java 7. Allerdings wurde die Meldung als “Not an issue” bewertet und die Meldung als resolved markiert.

https://bugs.openjdk.java.net/browse/JDK-8130464

Also ich hab mal quick & dirty eine Version gebaut, in der ich mittels
File.getCanonicalFile()
die Exception in Files.createDirectories umgehe. Also erst den Pfad mit symlink auflösen zum canonical path - und auf diesen canonical path dann Files.createDirectories(canonicalPath) aufrufen.
D.h. das obige Szenario mit dem sym link funzt mit dieser Version unter meiner Linux VM.

Danke an Stackoverflow!
https://stackoverflow.com/questions/813710/java-1-6-determine-symbolic-links

Bitte nicht hauen, wenn der Vorschlag nicht gefällt. Ist nur so ein Gedanke… und mal wieder so ein Fall, wo man vom 100.ten ins 1000.te kommt vor lauter Spezialfällen

[DerReisende77]

@rubikon und genau das ist mittlerweile das Problem mit Java. Funktionen gehen angeblich, dann stellt man fest daß sie auf einer Plattform nicht funktionieren, auf den anderen aber schon. Und beim Lösen von Bugs war Oracle teilweise sehr kreativ indem sie einfach ignoriert wurden. Und am Ende des Tages muss man spaghetti Code bauen der dann überall läuft.

Kannst du für deine Änderungen einen Pull request erstellen? Dann schau ich sie mir an und würde die integrieren wenn es überall funktioniert

[Ein ehemaliger Benutzer]

@DerReisende77 pull request schau ich mir heute Abend an, wie das geht. Ist aber eigentlich nur 1 Zeile Code.

Was ich gestern Nacht noch gesehen habe: mit per mklink oder junction erstellten links funktioniert meine Methode unter einem …
… ich traue mich nicht, es zu sagen…
…vielseits beliebten amerikanischen Betriebssystem aufs erste Hinschaue nicht. Dort gibt’s scheint’s keinen Unterschied zwischen canonical path und absolute path, so wie unter zumindest Debian… seufz
Aber immerhin würde Files.isSymbolikLink greifen. Muß mal nachdenken.

[DerReisende77]

@rubikon man kann es auch ruhig Windoof nennen du kannst die Funktion komplett auch gerne hier rein Posten. Dann sparst du dir den LR Aufwand wenn es nicht zu viel ist.
Aber es sollte schon auf allen Plattformen funktionieren

[Ein ehemaliger Benutzer]

@DerReisende77 Ich hab, parallel in Win10 und Debian testing im Wesentlichen mit einer 13.3.0 (master) gearbeitet, mit Ausnahme mediathek.tool.GuiFunktionenProgramme

In der besagten Datei hab ich einiges aus develop genommen und selbst mal ein wenig gespielt.
Ggfs. sind Ideen dabei, mit denen Du Dich anfreunden kannst.

GuiFunktionenProgramme.checkPathWriteable.txt

Also die Probleme, die ich hatte waren:

• Weder Linux noch Windows mögen als Parameter für Files.createDirectories einen symlink, sh. oben.
• Linux will für Files.createDirectories einen canonical path bei symlinks
• Windows gibt für mklink/junction dasselbe Ergebnis für absoluteFile und canonicalFile
• die Option LinkOption.NOFOLLOW_LINKS aus Files.isDirectory liefert false für Links, die auf ein Verzeichnis zeigen.

Ich hab mir dann gedacht:
Files.createDirectories besser nicht aufrufen, wenn isSymbolicLink true liefert.
Files.createDirectories insgesamt nur dann aufrufen, wenn path weder auf ein Verzeichnis noch auf einen Link zeigt.

Bei mir scheint’s zu laufen, aber ich hab aktuell die Option weg, einen Unterordner mit Thema anzulegen.

[DerReisende77]

@rubikon Ich habe gerade eine andere Version im develop branch eingecheckt die bei meinen Tests funktioniert. Kannst Du das mal bitte ausprobieren?

[Ein ehemaliger Benutzer]

@DerReisende77 ja, mach ich.
Das, was im Moment eingecheckt ist, ist beweisbar eine Kontradiktion und kann nicht funktionieren:

bool ret = false; // Initialisierung

ret wird aber auf keiner Stelle auf true gesetzt…

// die nicht auskommentiert ist. 

Krieg ich aber hin, hoffe ich - und dann meld ich mich. Danke schon mal!:thumbs_up:

[DerReisende77]

@rubikon das true kommt durch den temFile.delete wenn erfolgreich.

[Ein ehemaliger Benutzer]

@DerReisende77 oi,:face_screaming_in_fear: Sorry!:zipper-mouth_face:
Wo hatt ich denn da meine Augen beim Feixen! :confounded_face:
Na der :pistol: ging ja wohl nach hinten los schäm
Ich gehör ins Bett, bin bratfertig :face_with_head-bandage: :pile_of_poo:

Jedenfalls:
In einer modifizierten 13.3.0 mit diesem Code für checkPathWriteable/checkPathWriteable2 aus der aktuellen develop nimmt der Dialog zum “Film Speichern unter” Verzeichnisse mit und ohne symlinks erfolgreich an. Unter Windows und Linux.
Wenn ich dagegen als “Verzeichnis” einen Symlink auf eine Datei eintippe, dann heißt es, völlig zurecht, “Pfad ist nicht beschreibbar”.

läuft.:thumbs_up:

[DerReisende77]

@rubikon gut dann mache ich das hübsch Räume auf und checke die Finalversion ein.

[MenchenSued]

@DerReisende77 sagte in MV13.3.0: Speichern unter Linux:

Ich habe gerade eine Änderung in den develop branch eingebracht. Dieser sollte das Problem beheben.

Sorry für die späte Rückmeldung. Ich habe die Problematik mit symbolischen Links noch mal im aktuellen Develop Branch getestet. Scheint jetzt fehlerfrei unter Linux zu laufen. Danke.