[Toybox] [PATCH] df: -a should even show mounts we couldn't stat.

enh enh at google.com
Tue Feb 16 13:21:39 PST 2021


On Mon, Feb 15, 2021 at 6:31 AM Rob Landley <rob at 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 at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210216/0254a45b/attachment.html>


More information about the Toybox mailing list