Re: Coreutils enhancement: ls: add colorization of mountpoints

[Parke]

> On 10/17/23 12:05, Parke wrote:
> > I had forgotten about -F, and I do not use -F.  I am indifferent as to
> > whether or not mountpoints receive a custom --classify indicator.  I
> > was not planning on implementing such an indicator.

On Tue, Oct 17, 2023 at 10:09 PM Rob Landley <rob@landley.net> wrote:
> Which would be inconsistent behavior.

How so?  There is no --classify indicator for setuid, or setgid, etc.
Are these also inconsistent behavior?

A directory that is a mountpoint would still display the '/' indicator
with -F.  I wouldn't change that.

> > If bind mounts get their own st_dev device id (and they probably do?),
> > then they would be colored the same as mountpoints.  In my opinion,
> > this is expected and desired.
>
> They do not, but if it's a bind mount from a different filesystem you would
> color it as a mount point, and if it's a bind mount from elsewhere within the
> same filesystem you would not, introducing more inconsistent behavior.

Interesting.

> >> following symlinks with -L could get weird...
> >
> > Off the cuff, I'd say that the real (dereferenced) parent should be
> > checked.  (I.e. not the parent of the symlink.  This would result in
> > additional calls to stat().)
>
> I haven't looked at coreutils' implementation (I'm generally relucatant to 
> look
> at GPLv3 source when maintaining a BSD licensed project) but in general -L
> selects stat vs lstat so it only does a stat once,

After my previous email, I was thinking that -L might use stat()
instead of lstat().  This would seem to greatly complicate correctly
detecting mountpoints when -F is used.

> and under that implementation
> wouldn't -L  make symlinks show up as mount points?

Without additional checking (i.e. additional calls to stat() and/or
lstat(), and maybe realpath()), a symlink to a path on a different
filesystem would appear as a mountpoint.

One option would be to disable all colorization of mountpoints when -L
is specified.  (More inconsistent behavior?)

> The issue has larger scope than you propose to address, true. Users would have
> to understand what subset of the problem space your implementation addresses 
> in
> order to understand the tool's output. I.E. we'd have to know how the code is
> written to use it.

Or the behavior could be documented.

> > A fair point.  In the context of my personal workflows, being able to
> > always see Btrfs subvolumes and ZFS datasets (and bind mounts, and
> > other mountpoints as well) is valuable.
>
> grep $PWD /proc/mounts

Btrfs subvolumes are not listed in /proc/mounts.  Mounted subvolumes
are, but internally nested subvolumes are not.  This is different from
ZFS.  With ZFS every dataset is mounted individually, and a dataset
must be unmounted in order to be moved.

> which seems most useful for piping the output into "xargs -d '\n' umount" 
> since
> "umount -R dir" isn't a thing. (Yet.)

On my Linux systems, `umount -R dir` is a thing.

Cheers,

Parke