> 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 <r...@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
