Sigh, thunderbird crashed and I lost 8 gazillion open reply windows with half-composed messages. (Kmail used to remember messages being composed and open them back up again when it was relaunched. I miss kmail, but they tied it to a boat anchor of a desktop...)
Oh well, makes closing down my laptop so I can do a distro version upgrade only a half day instead of a full day's work... On 2/14/21 1:32 PM, Yi-yo Chiang wrote: > Hi Rob, > > I think the main purpose of the original patch is to show mounts whose > stat()/statvfs() failed. And the current one should do that? (I don't have any mount points I can't stat because my laptop doesn't do crazy things with linux security modules, maybe I can put one in a directory I can't read or something to simulate that...) > For example, an under-privileged user may be able to read /proc/mounts but > lack > the permission to stat(vfs) the mount point, so showing "-" is a way of saying > "I know this XXX device is being mount on YYY mount point, however for > whatever > reason I lack the means to get usage information from the filesystem". And the test I'm using is that the dev node is zero, which should never happen because you can't mount a NULL device. Instead of adding an external flag, it's the same in-band signaling it was using before. Previously, the logic would skip such mounts (you could get them in the list of mount points if all you wanted was the path, but we had no info about them so df would skip them). Elliott apparently wanted to display them as - - - - entries and I _think_ the current code does that but haven't tested it because I can stat all my filesystems because I'm not crazy enough to use LFS. > So I think 5f5f97f215bb accomplishes what the original change wants by not > skipping 0:0 device at all and gives "st_dev == 0" a special meaning of > "stat(mount point) failed". I think it does too, but haven't tested it, which is why I asked. > The only question I have left, is it guaranteed that st_dev must be zero or > left > unchanged when stat() fails? Or do we need to do something like, "if stat() / > statvfs() fails, ensure st_dev is zero" in portability.c to ensure the caller > knows that stat(mount point) failed? Linux leaves it alone. I can't speak for Apple. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
