<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021 at 10:54 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/16/21 3:24 PM, enh wrote:<br>
> There's a problem where if we can't stat it, we can't tell which one it is out<br>
> of /proc/mounts because we can't match the device. And you can't do an exact<br>
> match on the filename because "df ." is a directory under the mount point. I<br>
> would have to add plumbing to xabspath() and then do a longest match<br>
> fileunderdir(), which assumes that the /proc/mounts entry is always a cannonical<br>
> absolute path? (I _think_ that's true in current kernels but would have to read<br>
> the source)...<br>
> <br>
> is this a place where it would help if we switch from /proc/mounts to<br>
> /proc/self/mountinfo?<br>
<br>
Maybe, but I need more bandwidth to stare at that than I have available right<br>
now. (Look up when it showed up in the kernel,</blockquote><div><br></div><div>it passes that test at least, or i wouldn't have mentioned it: Linux 2.6.26 :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> find the Documentation file<br>
explaining what the fields are, evaluate whether the new fields are useful,<br></blockquote><div><br></div><div>for context, <a href="https://man7.org/linux/man-pages/man5/procfs.5.html">https://man7.org/linux/man-pages/man5/procfs.5.html</a> mentions mount and parent mount unique ids which is what i thought might be useful. there's a ton of other stuff too, and links to <a href="https://man7.org/linux/man-pages/man7/mount_namespaces.7.html">https://man7.org/linux/man-pages/man7/mount_namespaces.7.html</a> to explain some of it, which in turn -- despite being pretty long -- redirects readers to Documentation/filesystems/sharedsubtree.txt for more!<br></div><div><br></div><div>so, yeah, there does seem to be a large can of worms here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
figure out what impact if any this has on BSD or macos,</blockquote><div><br></div><div>they're already using completely different code, that already doesn't actually work (it doesn't give the same results as the macOS df, and i haven't had chance to look at why [since i don't know of anyone actually using it, and it's not in macos_defconfig anyway]). i think it's fine to break macOS a bit more for now, and i can worry about that later.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> and then compare against<br>
just _always_ doing the xabspath() string comparison and if that simplifies<br>
anything while providing sufficient behavior, plus the test suite needs updating...)<br></blockquote><div><br></div><div>it's not clear to me whether yi-yo is happy yet?</div><div><br></div><div>for my debian (strictly <a href="https://en.wikipedia.org/wiki/GLinux">https://en.wikipedia.org/wiki/GLinux</a>) desktop, the only difference between ToT toybox and coreutils right now is:</div><div><br></div><div>[coreutils]</div><div>/dev/mapper/glinux_20200515-root 425941416 120332512 283902564 30% /<br></div><div><br></div><div>versus:</div><div><br></div><div>[toybox]</div><div>/dev/dm-1 425941416 120333508 283901568 30% /<br></div><div><br></div><div>which i think is the opposite --- toybox seems to have dereferenced a symlink that coreutils _didn't_?</div><div><br></div><div>~$ ls -l /dev/mapper/glinux_20200515-root<br>lrwxrwxrwx 1 root root 7 Feb 16 14:02 /dev/mapper/glinux_20200515-root -> ../dm-1<br></div><div> </div><div>removing the xabspath() that's in df.c right now makes toybox match coreutils.</div><div><br></div><div>(okay, there's one other difference --- coreutils says "-" rather than "0%" for filesystems of size 0. so all the /sys or /proc stuff has "-" in the Use% column, not "0%", while still showing 0 in the other columns [because it did stat(), but stat() said that the fs was zero-sized, and that's a special case?].)</div><div><br></div><div>happy to send a patch/patches for either/both of those...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>