xnview erkennt Bilderordner nicht

Hallo,

schon länger bemerke ich ein etwas seltsames Verhalten von xnview. Ich kann derzeit nicht sagen, ob es damit zusammenhängt, dass das Programm nur noch als Flatpack installierbar ist.

Auf externen Datenträgern läuft alles, wie erwartet. Datenpartitionen auf der Systemplatte scheinen dagegen außerhalb der Vorstellungswelt der Programmierer zu liegen.

Generell sind bei meinen Rechnern die systemfernen Datenpartitionen benutzerunabhängig als /Daten eingehängt, sollten es mehrere sein (Canon unterstützt leider nur Windows und MacOS, das erfordert mindestens eine zusätzliche ntfs-Partition) mit angehängter Ziffer.

Normalerweise öffnet xnview ein Bild mit Anklicken. Auf externen Datenträgern passt auch die Anzahl der Bilder in einem Ordner. Auf der Datenpartition öffnet sich das angeklickte Bild auch, doch dann steht der Zähler auf 1/1 und Blättern funktioniert nicht. Starte ich xnview leer, erscheint der eingebaute Dateimanager mit dem home-Verzeichnis. Das ist nutzlos, dort habe ich keine Nutzdaten. Gehe ich zwei Ebenen hoch, bekomme ich nur die Ordner angezeigt, die das Betriebssystem von sich aus anlegt. Gebe ich in die Adressleiste /Daten ein, erhalte ich die Meldung, dass es dieses Verzeichnis nicht gäbe. Damit ist klar, warum das Blättern nicht funktioniert. Es wirkt so, als würden abweichende Speicherorte absichtlich ignoriert.

Gibt es Abhilfe? Ein Einbinden unter /home/Benutzername/ ist keine gute Idee, weil die Datenspeicherorte benutzerunabhängig erreichbar sein sollen.

rpm-Pakete für xnview MP und xnconvert gibt es zwar, doch beim Installationsversuch beklagt yast, dass das benötigte Paket libQt5Core.so.5 nicht aufzutreiben wäre.

Falk

Unwahrscheinlich, obwohl die fstab und die Vorgaben die Paranoia gewisser Entwickler bestens zeigt.

UUID=b9bb012b-d540-495b-b315-df6280f3242a / ext4 defaults 0 1

UUID=a13335cf-90ff-48ed-aab1-d5277dd0c98c /home ext4 data=ordered 0 2

UUID=9A7D-3B91 /boot/efi vfat utf8 0 2

UUID=17CBEE5712BB52BE /Daten ntfs fmask=111,dmask=000 0 0

In die Rechtefalle bin ich lange nicht mehr getreten und ich wüsste gerne, welcher Clown sich was mit der Vorgabe fmask=133, dmask=022 gedacht hat. Eine Datenpartition, die niemand außer root beschreiben kann, ist für die normale Nutzung eines Rechners nutzlos. Ist sie mit einem Linix-Dateisystem formatiert, ist das Freigeben für normale Nutzer noch etwas aufwändiger.

Falk

Da kam möglicherweise einiges falsch rüber.

Mit dem Dateisystem ntfs hat das erstmal nichts zu tun. Dass, wenn man nicht eingreift und gleich bei der Installation des Systems die in der fstab vorgegebenen Schreibrechte nur für root ändert, man von dieser Partition nichts hat, schrieb ich nur, weil Forentroll ein Rechteproblem vermutete. Den Einhängepunkt /Daten verwende ich seit meiner Frühzeit aus klassischer Faulheit. Die Datenspeicherorte sollen so weit oben im Dateibaum hängen wie möglich und auf keinen Fall unter einem Benutzernamen. Dann käme niemand anderes ran. /home ist ein Systemverzeichnis. Dort hinein kommen bei mir keine Nutzdaten. Den Grund sieht man sofort, wenn man die versteckten Dateien und Verzeichnisse anzeigt. Das ist bei mir immer und ausnahmslos der Fall.

Der Rechner, den ich hier im Urlaub mithabe, hat derzeit nur eine kleine Platte mit 256 GB. Das wird noch geändert, aber erst hinterher. Das zusätzliche Windows ist leider unverzichtbar, weil eben Canon nichts von Linux hält. Rohdatenkonvertierer gibt es auch unter Linux, aber die selbsttätige Objektivfehlerkorrektur halte ich für unersetzbar. Sie zu Fuß nachzubilden, geht schon, doch sind die nötigen Basteleien einfach zu langwierig. Eine weitere Datenpartition mit ext4 oder XFS verhält sich im Übrigen ebenso. Nur liegen die Rohdaten und die fertig bearbeiteten Bilder zu Hause auf externen Datenträgern. Mit denen hat xnview kein Problem.

Wenn ich den xnview-eigenen dateibrowser starte, dann tut der das nicht einstellbar in /home/Benutzername. Dort ist bei mir aber wie schon beschrieben nichts zu holen. Gehe ich dann nach oben, gibt es unter / die Einträge

app

bin

dev

etc

home

lib

lob64

proc

run

sbin

sys

tmp

usr

var

und als Zugabe .flatpack.info.

/Daten wird einfach nicht angezeigt, weil hier wohl jemand sehr mechanisch denkt. Nur bleibt das Murks.

Falk