On Mon, Feb 15, 2021 at 6:31 AM Rob Landley <r...@landley.net> wrote:
> 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...) > yeah, lgtm. > > 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. > to be clear, i was seeing this just on regular debian! > > 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. > annoyingly on macOS 11.2, / is device 0:0 --- ``` $ ./toybox stat / File: / Size: 640 Blocks: 0 IO Blocks: 512 directory Device: 1000004h/16777220d Inode: 2 Links: 20 Device type: 0,0 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ wheel) Access: 2020-01-01 00:00:00.000000000 -0800 Modify: 2020-01-01 00:00:00.000000000 -0800 Change: 2020-01-01 00:00:00.000000000 -0800 ``` but df's numbers all look wrong on macOS right now anyway, which is presumably why it isn't in macos_defconfig yet... > Rob > _______________________________________________ > Toybox mailing list > Toybox@lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net