Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #149542 > unrolled thread

Links in /home

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 14:25 +0100
    Re: Links in /home gunter-kuehne <gunter-kuehne@mail.de> - 2025-12-17 14:34 +0100
      Re: Links in /home Tim Ritberg <tim@server.invalid> - 2025-12-17 14:59 +0100
      Re: Links in /home Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-12-17 16:04 +0100
      Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 16:12 +0100
        Re: Links in /home Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-12-17 16:06 +0000
          Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 17:50 +0100
      Re: Links in /home Jan Schmidt <jan.schmidt@gmx.de> - 2025-12-17 16:21 +0100
    Re: Links in /home Dieter Schmickler <dieter.schmickler@t-online.de> - 2025-12-17 15:03 +0100
      Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 16:13 +0100
        Re: Links in /home Jan Schmidt <jan.schmidt@gmx.de> - 2025-12-17 16:24 +0100
          Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 17:42 +0100
    Re: Links in /home Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-17 15:43 +0100
      Re: Links in /home michaelnoeusenet@mac.com (Michael Noe) - 2025-12-17 16:40 +0100
        Re: Links in /home Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-12-17 17:29 +0100
          Re: Links in /home michaelnoeusenet@mac.com (Michael Noe) - 2025-12-17 18:09 +0100
          Re: Links in /home Jens Schuessler <j.schuess@nurfuerspam.de> - 2025-12-18 06:07 +0100
            Re: Links in /home michaelnoeusenet@mac.com (Michael Noe) - 2025-12-18 11:59 +0100
              Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-18 13:25 +0100
                Re: Links in /home michaelnoeusenet@mac.com (Michael Noe) - 2025-12-18 16:43 +0100
      Re: Links in /home Claus Reibenstein <creibens@gmail.com> - 2025-12-18 16:08 +0100
        Re: Links in /home Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2025-12-18 19:23 +0000
        Re: Links in /home Stefan Reuther <stefan.news@arcor.de> - 2025-12-19 11:10 +0100
    Re: Links in /home Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-12-17 16:04 +0100
      Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 17:40 +0100
        Re: Links in /home Frank Miller <miller@posteo.ee> - 2025-12-17 18:34 +0100
          Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 21:29 +0100
            Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 22:00 +0100
              Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 22:12 +0100
                Re: Links in /home Frank Miller <miller@posteo.ee> - 2025-12-17 23:25 +0100
                Re: Links in /home Claus Reibenstein <creibens@gmail.com> - 2025-12-18 16:16 +0100
                  Re: Links in /home Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-12-18 18:00 +0100
                  Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-18 18:06 +0100
                  Re: Links in /home Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2025-12-18 19:16 +0000
        Re: Links in /home Hergen Lehmann <hlehmann-usenet24@snafu.de> - 2025-12-17 19:13 +0100
        Re: Links in /home gunter-kuehne <gunter-kuehne@mail.de> - 2025-12-18 13:52 +0100
    Re: Links in /home (gelöst) Matthias Gerds <m.gerds@posteo.de> - 2025-12-17 22:54 +0100
      Re: Links in /home (gelöst) Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-12-18 22:27 +0100
    Re: Links in /home Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-12-18 22:24 +0100
      Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-18 22:27 +0100
      Re: Links in /home Matthias Gerds <m.gerds@posteo.de> - 2025-12-18 22:29 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#149571

Hermann Riemann schrieb am 17.12.25 um 15:43:

> $HOME kommt mir wie ein Müllabladeplatz für unterschiedliche Anwendungen 
> vor. Bei Neuinstallatation muss ich halt .emacs neben /ec/hosts.
> aus /eigene_Dateien kopieren.

Mit Verlaub: Du hast keine Ahnung.

Deinem Geschreibsel nach zu urteilen, hast du bis vor Kurzem noch mit
Windows gearbeitet und versuchst nun kramphaft, dein Linux so aussehen
zu lassen wie Windows. Lass das lieber sein und versuche statt dessen,
Linux zu verstehen und korrekt anzuwenden.

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#149577

Claus Reibenstein schrieb am 18/12/2025 16:08:

> Hermann Riemann schrieb am 17.12.25 um 15:43:
>
>> $HOME kommt mir wie ein Müllabladeplatz für unterschiedliche Anwendungen 
>> vor. Bei Neuinstallatation muss ich halt .emacs neben /ec/hosts.
>> aus /eigene_Dateien kopieren.
>
> Mit Verlaub: Du hast keine Ahnung.
>
> Deinem Geschreibsel nach zu urteilen, hast du bis vor Kurzem noch mit
> Windows gearbeitet und versuchst nun kramphaft,

[ ] Du kennst Hermann.

Nein, hat er nicht, aber seine Gedankengänge sind manchmal etwas schwer
nachvollziehbar.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#149582

Am 18.12.2025 um 16:08 schrieb Claus Reibenstein:
> Hermann Riemann schrieb am 17.12.25 um 15:43:
>> $HOME kommt mir wie ein Müllabladeplatz für unterschiedliche Anwendungen 
>> vor. Bei Neuinstallatation muss ich halt .emacs neben /ec/hosts.
>> aus /eigene_Dateien kopieren.
> 
> Mit Verlaub: Du hast keine Ahnung.
> 
> Deinem Geschreibsel nach zu urteilen, hast du bis vor Kurzem noch mit
> Windows gearbeitet und versuchst nun kramphaft, dein Linux so aussehen
> zu lassen wie Windows. Lass das lieber sein und versuche statt dessen,
> Linux zu verstehen und korrekt anzuwenden.

Was ist denn "korrekt angewendet"?

Es gibt durchaus Gründe für so ein Setup. Ich habe das jahrzehntelang
genau so eingesetzt.

Man kann damit die "eigenen Dateien" zwischen Betriebssystemen teilen
(Dual Boot), ohne dass sich irgendwelche Dotfiles ins Gehege kommen. Man
kann die eigenen Dateien auf einen anderen Datenträger packen, den man
beim Rechnerupgrade ggf. mitnimmt, und der eine andere Backupstrategie
bekommt. Man kann das Betriebssystem auf eine teure SSD packen, für die
Schwuppdizität, und die eigenen Dateien (insb. die selten benötigten wie
z.B. Foto-Archive) auf eine billige HDD.

Erst beim Bau meines letzten Rechners war die Hardware soweit und so
preiswert, dass "alles, inkl. der Archive, auf einen Datenträger" und
"Backupstrategie ist das Vollbackup, völlig egal, wenn da noch
irgendwelche Tempfiles mit dabei sind" sinnvoll sind (und das Microsoft
mir genug Bullshit aufdrücken will, dass da Windows keine Rolle mehr
spielen muss).


  Stefan

[toc] | [prev] | [next] | [standalone]

#149552

Am 17.12.25 um 14:25 schrieb Matthias Gerds:

> Habe meine Fotosammlung auf einer anderen Platte und sie daher per
> symbolischem Link zum Homeverzeichnis verknüpft.
> Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
> nicht zurecht kommen und automatisch so was Komisches wie
> 
> /run/user/1000/doc/e97e4e78/Fotos
> [...]
> 
> Wo liegt der Fehler? Falsche Berechtigungen?

It's a feature, not a bug!

Der Umweg über "/run/user/<userid>/.../<medium>/<verzeichnis>"
hat den Vorteil, das auch temporär gemountete Datenträger (z.B. 
USB-Sticks sowie nicht ständig verfügbare Netzlaufwerke) verlinkt werden 
können. Die Verzeichnisse unter /run/user werden automatisch gelöscht 
und am selben Ort wieder angelegt, wenn die Medien entfernt und wieder 
verfügbar werden.

Wenn es dich stört, gib den gewünschten Pfad einfach manuell ein, statt 
den Dateiauswahl-Dialog des Betriebssystems zu benutzen.

[toc] | [prev] | [next] | [standalone]

#149556

Am Wed, 17 Dec 2025 16:04:52 +0100
schrieb Hergen Lehmann <hlehmann-usenet24@snafu.de>:

> Am 17.12.25 um 14:25 schrieb Matthias Gerds:
> 
> > Habe meine Fotosammlung auf einer anderen Platte und sie daher per
> > symbolischem Link zum Homeverzeichnis verknüpft.
> > Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
> > nicht zurecht kommen und automatisch so was Komisches wie
> > 
> > /run/user/1000/doc/e97e4e78/Fotos
> > [...]
> > 
> > Wo liegt der Fehler? Falsche Berechtigungen?
> 
> It's a feature, not a bug!
> 
> Der Umweg über "/run/user/<userid>/.../<medium>/<verzeichnis>"
> hat den Vorteil, das auch temporär gemountete Datenträger (z.B. 
> USB-Sticks sowie nicht ständig verfügbare Netzlaufwerke) verlinkt
> werden können. Die Verzeichnisse unter /run/user werden automatisch
> gelöscht und am selben Ort wieder angelegt, wenn die Medien entfernt
> und wieder verfügbar werden.

Ist mir schon aufgefallen. Verstehe ich auch für temporäre USB-Teile
etc., aber für ständig gemountete Datenträger?
 
> Wenn es dich stört, gib den gewünschten Pfad einfach manuell ein,
> statt den Dateiauswahl-Dialog des Betriebssystems zu benutzen.

Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
/run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
machen das. Stört mich. Dann bleibt wohl nur die Lösung als Mount in
/etc/fstab, wie es andere hier offenbar gelöst haben. Aber dann erkennt
man im Dateimanager wahrscheinlich nicht mehr, dass das eigentlich ein
Link zu einem Ordner auf einem anderen Datenträger ist, oder?

:-(

[toc] | [prev] | [next] | [standalone]

#149560

Matthias Gerds wrote:
[..snip..]
> Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
> machen das. Stört mich. Dann bleibt wohl nur die Lösung als Mount in
> /etc/fstab, wie es andere hier offenbar gelöst haben. Aber dann erkennt
> man im Dateimanager wahrscheinlich nicht mehr, dass das eigentlich ein
> Link zu einem Ordner auf einem anderen Datenträger ist, oder?

Also, wenn die Datenträger ohnehin ständig gemountet sind, liegt IMO
eine Einbindung via fstab nehr als nahe. Und im Dateimanager gibt es
eigentlich auch keinen Grund, kenntlich zu machen *dass* es ein anderer
Datenträger ist.
Es ist ja schließlich nicht Windows, wo es auf Laufwerke mit verschiedenen
Buchstaben ankommen kann.

[toc] | [prev] | [next] | [standalone]

#149562

Am Wed, 17 Dec 2025 18:34:12 +0100
schrieb Frank Miller <miller@posteo.ee>:

> Matthias Gerds wrote:
> [..snip..]
> > Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> > /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
> > machen das. Stört mich. Dann bleibt wohl nur die Lösung als Mount in
> > /etc/fstab, wie es andere hier offenbar gelöst haben. Aber dann
> > erkennt man im Dateimanager wahrscheinlich nicht mehr, dass das
> > eigentlich ein Link zu einem Ordner auf einem anderen Datenträger
> > ist, oder?
> 
> Also, wenn die Datenträger ohnehin ständig gemountet sind, liegt IMO
> eine Einbindung via fstab nehr als nahe. Und im Dateimanager gibt es
> eigentlich auch keinen Grund, kenntlich zu machen *dass* es ein
> anderer Datenträger ist.
> Es ist ja schließlich nicht Windows, wo es auf Laufwerke mit
> verschiedenen Buchstaben ankommen kann.

Mal ehrlich, ich halte dieses Verhalten einiger Programme für Unfug,
schließlich gibt es ja auch einige Programme (digikam, gthumb), die
weder mit Ordnern auf anderen Laufwerken noch mit symbolischen Links zu
diesen in /home/user/ ein Problem haben: digikam, gthumb und ...?
Andere wieder sehen in der Dateiauswahl noch nicht einmal /mnt, was
ich überhaupt nicht verstehe: XnView, Pix, und einige andere
Fotomanager. Vermisse das eigentlich ziemlich gute Picasa (Google),
das man aber nur noch per Wine (32bit) unter Linux zum Laufen bekommt.

Warum sollte ich jetzt für jedes in /home/user/ verlinkte Verzeichnis
einen extra Eintrag in /etc/fstab machen? Ich habe so einige Ordner,
die auf anderen (ständig gemounteten) Datenträgern liegen!

Nö.


M:
 

[toc] | [prev] | [next] | [standalone]

#149563

Am Wed, 17 Dec 2025 21:29:12 +0100
schrieb Matthias Gerds <m.gerds@posteo.de>:

> Am Wed, 17 Dec 2025 18:34:12 +0100
> schrieb Frank Miller <miller@posteo.ee>:
> 
> > Matthias Gerds wrote:
> > [..snip..]
> > > Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> > > /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
> > > machen das. Stört mich. Dann bleibt wohl nur die Lösung als Mount
> > > in /etc/fstab, wie es andere hier offenbar gelöst haben. Aber dann
> > > erkennt man im Dateimanager wahrscheinlich nicht mehr, dass das
> > > eigentlich ein Link zu einem Ordner auf einem anderen Datenträger
> > > ist, oder?
> > 
> > Also, wenn die Datenträger ohnehin ständig gemountet sind, liegt IMO
> > eine Einbindung via fstab nehr als nahe. Und im Dateimanager gibt es
> > eigentlich auch keinen Grund, kenntlich zu machen *dass* es ein
> > anderer Datenträger ist.
> > Es ist ja schließlich nicht Windows, wo es auf Laufwerke mit
> > verschiedenen Buchstaben ankommen kann.
> 
> Mal ehrlich, ich halte dieses Verhalten einiger Programme für Unfug,
> schließlich gibt es ja auch einige Programme (digikam, gthumb), die
> weder mit Ordnern auf anderen Laufwerken noch mit symbolischen Links
> zu diesen in /home/user/ ein Problem haben: digikam, gthumb und ...?
> Andere wieder sehen in der Dateiauswahl noch nicht einmal /mnt, was
> ich überhaupt nicht verstehe: XnView, Pix, und einige andere
> Fotomanager. Vermisse das eigentlich ziemlich gute Picasa (Google),
> das man aber nur noch per Wine (32bit) unter Linux zum Laufen bekommt.
> 
> Warum sollte ich jetzt für jedes in /home/user/ verlinkte Verzeichnis
> einen extra Eintrag in /etc/fstab machen? Ich habe so einige Ordner,
> die auf anderen (ständig gemounteten) Datenträgern liegen!

Ich glaube, ich weiß jetzt, woran dieses Verhalten einiger Programme
liegt (öffnen/sehen keine Links): Das sind jene, die ich per Flatpak
installiert habe. 
digikam und gthumb stammen nämlich aus dem regulären Repo und zeigen
das Verhalten nicht (können mit Links umgehen). Müsste meinen Verdacht
noch mal mit anderen Programmen testen ...

M: 

[toc] | [prev] | [next] | [standalone]

#149564

Am Wed, 17 Dec 2025 22:00:49 +0100
schrieb Matthias Gerds <m.gerds@posteo.de>:

> Am Wed, 17 Dec 2025 21:29:12 +0100
> schrieb Matthias Gerds <m.gerds@posteo.de>:
> 
> > Am Wed, 17 Dec 2025 18:34:12 +0100
> > schrieb Frank Miller <miller@posteo.ee>:
> > 
> > > Matthias Gerds wrote:
> > > [..snip..]
> > > > Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> > > > /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle
> > > > Programme machen das. Stört mich. Dann bleibt wohl nur die
> > > > Lösung als Mount in /etc/fstab, wie es andere hier offenbar
> > > > gelöst haben. Aber dann erkennt man im Dateimanager
> > > > wahrscheinlich nicht mehr, dass das eigentlich ein Link zu
> > > > einem Ordner auf einem anderen Datenträger ist, oder?
> > > 
> > > Also, wenn die Datenträger ohnehin ständig gemountet sind, liegt
> > > IMO eine Einbindung via fstab nehr als nahe. Und im Dateimanager
> > > gibt es eigentlich auch keinen Grund, kenntlich zu machen *dass*
> > > es ein anderer Datenträger ist.
> > > Es ist ja schließlich nicht Windows, wo es auf Laufwerke mit
> > > verschiedenen Buchstaben ankommen kann.
> > 
> > Mal ehrlich, ich halte dieses Verhalten einiger Programme für Unfug,
> > schließlich gibt es ja auch einige Programme (digikam, gthumb), die
> > weder mit Ordnern auf anderen Laufwerken noch mit symbolischen Links
> > zu diesen in /home/user/ ein Problem haben: digikam, gthumb und ...?
> > Andere wieder sehen in der Dateiauswahl noch nicht einmal /mnt, was
> > ich überhaupt nicht verstehe: XnView, Pix, und einige andere
> > Fotomanager. Vermisse das eigentlich ziemlich gute Picasa (Google),
> > das man aber nur noch per Wine (32bit) unter Linux zum Laufen
> > bekommt.
> > 
> > Warum sollte ich jetzt für jedes in /home/user/ verlinkte
> > Verzeichnis einen extra Eintrag in /etc/fstab machen? Ich habe so
> > einige Ordner, die auf anderen (ständig gemounteten) Datenträgern
> > liegen!
> 
> Ich glaube, ich weiß jetzt, woran dieses Verhalten einiger Programme
> liegt (öffnen/sehen keine Links): Das sind jene, die ich per Flatpak
> installiert habe. 
> digikam und gthumb stammen nämlich aus dem regulären Repo und zeigen
> das Verhalten nicht (können mit Links umgehen). Müsste meinen Verdacht
> noch mal mit anderen Programmen testen ...

Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps laufen
in einer Sandbox, also ist das Verhalten (keine verlinkten Ordner)
logisch.
Abhilfe soll Flatseal bringen, mit dem man geeignete Berechtigungen
ändern kann.

M:


-- 

[toc] | [prev] | [next] | [standalone]

#149566

Matthias Gerds wrote:
> Am Wed, 17 Dec 2025 22:00:49 +0100
> schrieb Matthias Gerds <m.gerds@posteo.de>:
> 
>> Am Wed, 17 Dec 2025 21:29:12 +0100
>> schrieb Matthias Gerds <m.gerds@posteo.de>:
>> 
>> > Am Wed, 17 Dec 2025 18:34:12 +0100
>> > schrieb Frank Miller <miller@posteo.ee>:
>> > 
>> > > Matthias Gerds wrote:
>> > > [..snip..]
>> > > > Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
>> > > > /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle
>> > > > Programme machen das. Stört mich. Dann bleibt wohl nur die
>> > > > Lösung als Mount in /etc/fstab, wie es andere hier offenbar
>> > > > gelöst haben. Aber dann erkennt man im Dateimanager
>> > > > wahrscheinlich nicht mehr, dass das eigentlich ein Link zu
>> > > > einem Ordner auf einem anderen Datenträger ist, oder?
>> > > 
>> > > Also, wenn die Datenträger ohnehin ständig gemountet sind, liegt
>> > > IMO eine Einbindung via fstab nehr als nahe. Und im Dateimanager
>> > > gibt es eigentlich auch keinen Grund, kenntlich zu machen *dass*
>> > > es ein anderer Datenträger ist.
>> > > Es ist ja schließlich nicht Windows, wo es auf Laufwerke mit
>> > > verschiedenen Buchstaben ankommen kann.
>> > 
>> > Mal ehrlich, ich halte dieses Verhalten einiger Programme für Unfug,
>> > schließlich gibt es ja auch einige Programme (digikam, gthumb), die
>> > weder mit Ordnern auf anderen Laufwerken noch mit symbolischen Links
>> > zu diesen in /home/user/ ein Problem haben: digikam, gthumb und ...?
>> > Andere wieder sehen in der Dateiauswahl noch nicht einmal /mnt, was
>> > ich überhaupt nicht verstehe: XnView, Pix, und einige andere
>> > Fotomanager. Vermisse das eigentlich ziemlich gute Picasa (Google),
>> > das man aber nur noch per Wine (32bit) unter Linux zum Laufen
>> > bekommt.
>> > 
>> > Warum sollte ich jetzt für jedes in /home/user/ verlinkte
>> > Verzeichnis einen extra Eintrag in /etc/fstab machen? Ich habe so
>> > einige Ordner, die auf anderen (ständig gemounteten) Datenträgern
>> > liegen!
>> 
>> Ich glaube, ich weiß jetzt, woran dieses Verhalten einiger Programme
>> liegt (öffnen/sehen keine Links): Das sind jene, die ich per Flatpak
>> installiert habe. 
>> digikam und gthumb stammen nämlich aus dem regulären Repo und zeigen
>> das Verhalten nicht (können mit Links umgehen). Müsste meinen Verdacht
>> noch mal mit anderen Programmen testen ...
> 
> Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps laufen
> in einer Sandbox, also ist das Verhalten (keine verlinkten Ordner)
> logisch.
> Abhilfe soll Flatseal bringen, mit dem man geeignete Berechtigungen
> ändern kann.

Danke für deine Nachforschungen. Das bestärkt mich in meiner unerfahrenen
Meinung bzgl. Flatpak, solche Programme nicht verwenden zu wollen.

[toc] | [prev] | [next] | [standalone]

#149572

Matthias Gerds schrieb am 17.12.25 um 22:12:

> Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps laufen
> in einer Sandbox, also ist das Verhalten (keine verlinkten Ordner)
> logisch.

Flatpak ist Schrott, ebenso Snap. Lass besser von beidem die Finger. Zum
Einen müllen sie die Festplatten unnötig voll, zum Anderen widersprechen
sie dem Urgedanken unixoider Systeme.

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#149574

Claus Reibenstein <creibens@gmail.com> wrote:
>Matthias Gerds schrieb am 17.12.25 um 22:12:
>> Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps laufen
>> in einer Sandbox, also ist das Verhalten (keine verlinkten Ordner)
>> logisch.
>
>Flatpak ist Schrott, ebenso Snap. Lass besser von beidem die Finger. Zum
>Einen müllen sie die Festplatten unnötig voll, zum Anderen widersprechen
>sie dem Urgedanken unixoider Systeme.

Dem Urgedanken unixoider Systeme widerspricht so einiges, zum Beispiel
dass die meisten Linux-Arbeitsplatz-Installationen exakt einen User
und exakt eine pro Zeit aktive Benutzersession haben dürften.

Flatpak taugt, wenn man Dinge wegsperren möchte, die nicht aus der
Distribution kommen und deren Auswirkungen auf das System minimieren
möchte. Telegram Desktop ist zum Beispiel so ein Fall, und mein wine
hätte ich auch gerne mitsamt der zwei Windows-Anwendungen die ich
immer noch nutzen muss irgendwo hin gelegt wo es mir den wichtigen
Teil meiner Arbeit nicht beeinflussen kann.

Letzteres leider bisher ohne Erfolg.

Grüße
Marc
-- 
----------------------------------------------------------------------------
Marc Haber         |   " Questions are the         | Mailadresse im Header
Rhein-Neckar, DE   |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[toc] | [prev] | [next] | [standalone]

#149575

Am Thu, 18 Dec 2025 16:16:55 +0100
schrieb Claus Reibenstein <creibens@gmail.com>:

> Matthias Gerds schrieb am 17.12.25 um 22:12:
> 
> > Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps
> > laufen in einer Sandbox, also ist das Verhalten (keine verlinkten
> > Ordner) logisch.
> 
> Flatpak ist Schrott, ebenso Snap. Lass besser von beidem die Finger.
> Zum Einen müllen sie die Festplatten unnötig voll, zum Anderen
> widersprechen sie dem Urgedanken unixoider Systeme.

Also Snap möchte ich auch nicht gerne drauf haben wegen der
Abhängigkeit von Canonical's Extratouren. Aber auch unter Debian kommt
man um Flatpak mMn oft nicht herum, weil es inzwischen viele Pakete
gibt, die es nur als Flatpak, Snap oder AppImage gibt. Die sind meist
auch aktueller gegenüber den vielfach veralteten älteren Debian-Versionen.
Und zum selbst Kompilieren habe ich einfach keine Lust.

Auch grundsätzlich ist die Sandbox-Idee ja auch nicht schlecht.
Blicke ich da nur nicht ganz durch, weil manche Pakete das SU-Pw
brauchen und manche nicht. Auch die Verwaltung durch Plasma-Discover
ist fehlerhaft, weshalb ich die inzwischen lieber über die Konsole
verwalte.


M:
 

--
Betriebssystem: Debian GNU/Linux 13
KDE-Plasma-Version: 6.3.6
KDE-Frameworks-Version: 6.13.0
Qt-Version: 6.8.2
Kernel-Version: 6.12.57+deb13-amd64 (64-bit)
Grafik-Plattform: Wayland

[toc] | [prev] | [next] | [standalone]

#149576

Claus Reibenstein schrieb am 18/12/2025 16:16:

> Matthias Gerds schrieb am 17.12.25 um 22:12:
>
>> Sorry, dass ich da nicht früher drauf gekommen bin. Flatpak Apps laufen
>> in einer Sandbox, also ist das Verhalten (keine verlinkten Ordner)
>> logisch.
>
> Flatpak ist Schrott, ebenso Snap.

Blödsinn, ohne Software-Container gäbe es viele Software gar nicht und
wären so manche Geräte nicht mit Linux verwendbar, weil den
Distributionen die zu unwichtig sind, dass sie die in ihr Repository
aufnehmen und für die Software-Entwickler wäre es eine Zumutung, für
mehrere Distributionen compilieren und paketieren zu müssen und das
mindestens jährlich für jedes neue Release der jeweiligen
Distribution.
Als konkretes Beispiel, dieses USB Oszilloskop:
https://www.lab-nation.com/app

> zum Anderen widersprechen
> sie dem Urgedanken unixoider Systeme.

Seit der Entwicklung der ersten *NIXen hat sich die Welt ein /bisschen/
weiter gedreht.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#149561

Am 17.12.25 um 17:40 schrieb Matthias Gerds:

> Am Wed, 17 Dec 2025 16:04:52 +0100
> schrieb Hergen Lehmann <hlehmann-usenet24@snafu.de>:
>> Der Umweg über "/run/user/<userid>/.../<medium>/<verzeichnis>"
>> hat den Vorteil, das auch temporär gemountete Datenträger (z.B.
>> USB-Sticks sowie nicht ständig verfügbare Netzlaufwerke) verlinkt
>> werden können. Die Verzeichnisse unter /run/user werden automatisch
>> gelöscht und am selben Ort wieder angelegt, wenn die Medien entfernt
>> und wieder verfügbar werden.
> 
> Ist mir schon aufgefallen. Verstehe ich auch für temporäre USB-Teile
> etc., aber für ständig gemountete Datenträger?

Ständig gemountete Datenträger solltest du mit Wunschpfad in die 
/etc/fstab eintragen.


> Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
> machen das. Stört mich.

Das ist letztlich die Entscheidung des Programmierers, ob er den vom 
Benutzer eingegebenen Pfad oder den via realpath() aufgelösten, 
tatsächlichen Pfad in die Konfiguration speichert.


> Dann bleibt wohl nur die Lösung als Mount in
> /etc/fstab, wie es andere hier offenbar gelöst haben. 

Ja. Entweder hart das physische Medium oder über einen fest verdrahteten 
Link über einen "bind"-Eintrag. Grundsätzlich hat die fstab den 
Nachteil, das der Datenträger bereits beim booten verfügbar sein muss.


> Aber dann erkennt
> man im Dateimanager wahrscheinlich nicht mehr, dass das eigentlich ein
> Link zu einem Ordner auf einem anderen Datenträger ist, oder?

So ist es.

[toc] | [prev] | [next] | [standalone]

#149570

Am 17.12.25 um 17:40 schrieb Matthias Gerds:
> Am Wed, 17 Dec 2025 16:04:52 +0100
> schrieb Hergen Lehmann <hlehmann-usenet24@snafu.de>:
> 
>> Am 17.12.25 um 14:25 schrieb Matthias Gerds:
>>
>>> Habe meine Fotosammlung auf einer anderen Platte und sie daher per
>>> symbolischem Link zum Homeverzeichnis verknüpft.
>>> Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
>>> nicht zurecht kommen und automatisch so was Komisches wie
>>>
>>> /run/user/1000/doc/e97e4e78/Fotos
>>> [...]
>>>
>>> Wo liegt der Fehler? Falsche Berechtigungen?
>>
>> It's a feature, not a bug!
>>
>> Der Umweg über "/run/user/<userid>/.../<medium>/<verzeichnis>"
>> hat den Vorteil, das auch temporär gemountete Datenträger (z.B.
>> USB-Sticks sowie nicht ständig verfügbare Netzlaufwerke) verlinkt
>> werden können. Die Verzeichnisse unter /run/user werden automatisch
>> gelöscht und am selben Ort wieder angelegt, wenn die Medien entfernt
>> und wieder verfügbar werden.
> 
> Ist mir schon aufgefallen. Verstehe ich auch für temporäre USB-Teile
> etc., aber für ständig gemountete Datenträger?
>   
>> Wenn es dich stört, gib den gewünschten Pfad einfach manuell ein,
>> statt den Dateiauswahl-Dialog des Betriebssystems zu benutzen.
> 
> Wenn ich den konkreten Pfad eingebe, trägt der trotzdem den
> /run/user/<user-id>...-Pfad ein. Wie gesagt, nicht alle Programme
> machen das. Stört mich. Dann bleibt wohl nur die Lösung als Mount in
> /etc/fstab, wie es andere hier offenbar gelöst haben. Aber dann erkennt
> man im Dateimanager wahrscheinlich nicht mehr, dass das eigentlich ein
> Link zu einem Ordner auf einem anderen Datenträger ist, oder?
> 
> :-(
> 
Naja wen du ihn anklickst, wird dir natürlich das Dateisystem und die 
Größe angezeigt. interessant ist dann das in dem gemounteten Ordner(Bei 
mir z.B. /home/gunter/Musik) ein lost+found angelegt wird.
Das sieht man bei entsprechenden Einstellungen. Allerdings benutze in 
meist den Krusader als Dateimanager. Ist ne reine Bequemlichkeitsfrage)


-- 
Kleinmut und Stolz, aus diesem Holz
Schuf der Mensch sich am sechsten Tag Gott.

[toc] | [prev] | [next] | [standalone]

#149565 — Re: Links in /home (gelöst)

Am Wed, 17 Dec 2025 14:25:58 +0100
schrieb Matthias Gerds <m.gerds@posteo.de>:

> Hey!
> 
> Habe meine Fotosammlung auf einer anderen Platte und sie daher per
> symbolischem Link zum Homeverzeichnis verknüpft.
> Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
> nicht zurecht kommen und automatisch so was Komisches wie
> 
> /run/user/1000/doc/e97e4e78/Fotos 
> 
> als Sammlungsort eintragen statt
> /home/user/Fotos bzw. 
> /home/user/Bilder 
> 
> Andere (digikam) wiederum haben keine Probleme damit.
> 
> Auch Dolphin (KDE-Dateimanager) kann in der Seitenleiste (Ordnerliste)
> keine neuen Ordnereinträge von Links anlegen. Früher ging das aber (so
> weit ich mich erinnere).
> 
> Wo liegt der Fehler? Falsche Berechtigungen?
> Debian- oder KDE-Issue?

Ist mir jetzt eigentlich ein bisschen peinlich. Das von mir bemängelte
Verhalten (keine Links, keine anderen Laufwerke) liegt an Flatpak.
Die über Flatpak installierten Pakete laufen ja in einer Sandbox, und
können daher nicht ohne Weiteres auf andere Laufwerke und Links auf
diese zugreifen.
Mit Flatseal (Flatpak Berechtigungsmanager) kann man das aber ändern. 
Sorry, dass ich nicht früher darauf gekommen bin.

:-) (bitte nicht hauen)

M: 

[toc] | [prev] | [next] | [standalone]

#149580 — Re: Links in /home (gelöst)

Am 17.12.25 um 22:54 schrieb Matthias Gerds:
> Ist mir jetzt eigentlich ein bisschen peinlich. Das von mir bemängelte
> Verhalten (keine Links, keine anderen Laufwerke) liegt an Flatpak.
> Die über Flatpak installierten Pakete laufen ja in einer Sandbox, und
> können daher nicht ohne Weiteres auf andere Laufwerke und Links auf
> diese zugreifen.
> Mit Flatseal (Flatpak Berechtigungsmanager) kann man das aber ändern.
> Sorry, dass ich nicht früher darauf gekommen bin.
Ah, trotzdem hilfreich, falls man mal darüber fällt.

Um Flatpack & Co mache ich bisher noch einen möglichst großen Bogen. 
Hauptsächlich wegen des wesentlich höheren Ressourcenbedarfs und der 
zuweilen fehlenden Sicherheitspatches.


Marcel

[toc] | [prev] | [next] | [standalone]

#149578

Am 17.12.25 um 14:25 schrieb Matthias Gerds:
> Habe meine Fotosammlung auf einer anderen Platte und sie daher per
> symbolischem Link zum Homeverzeichnis verknüpft.
> Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
> nicht zurecht kommen und automatisch so was Komisches wie
> 
> /run/user/1000/doc/e97e4e78/Fotos

???

> als Sammlungsort eintragen statt
> /home/user/Fotos bzw.
> /home/user/Bilder

Symlinks habe ich seit Jahren an der Stelle auch (verschiedene Ubuntu 
und Mint, aber kein KDE) und bei mir zeigen die sogar auf Verzeichnisse 
andere Rechner (nfs4 mit krb5p).

Derlei ist mir aber noch nicht unter gekommen. Ist die Platte vllt. 
manchmal nicht erreichbar?

> Wo liegt der Fehler? Falsche Berechtigungen?

Seit wann haben Links Berechtigungen?
Wenn natürlich das Ziel komplett andere Berechtigungen hat als home, 
kann das schon Auswirkungen haben.


Marcel

[toc] | [prev] | [next] | [standalone]

#149579

Am Thu, 18 Dec 2025 22:24:20 +0100
schrieb Marcel Mueller <news.5.maazl@spamgourmet.org>:

> Am 17.12.25 um 14:25 schrieb Matthias Gerds:
> > Habe meine Fotosammlung auf einer anderen Platte und sie daher per
> > symbolischem Link zum Homeverzeichnis verknüpft.
> > Blöd nur, dass so einige Programme (u. a. KPhotoAlbum, XnView) damit
> > nicht zurecht kommen und automatisch so was Komisches wie
> > 
> > /run/user/1000/doc/e97e4e78/Fotos
> 
> ???
> 
> > als Sammlungsort eintragen statt
> > /home/user/Fotos bzw.
> > /home/user/Bilder
> 
> Symlinks habe ich seit Jahren an der Stelle auch (verschiedene Ubuntu 
> und Mint, aber kein KDE) und bei mir zeigen die sogar auf
> Verzeichnisse andere Rechner (nfs4 mit krb5p).
> 
> Derlei ist mir aber noch nicht unter gekommen. Ist die Platte vllt. 
> manchmal nicht erreichbar?
> 
> > Wo liegt der Fehler? Falsche Berechtigungen?
> 
> Seit wann haben Links Berechtigungen?
> Wenn natürlich das Ziel komplett andere Berechtigungen hat als home, 
> kann das schon Auswirkungen haben.

Ist doch aufgeklärt ... siehe 1 tiefer!

M:

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web