Date: Mon, 5 Mar 2018 15:30:05 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> Cc: Bryan Drewery <bdrewery@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r330436 - head/bin/chflags Message-ID: <20180305140228.P935@besplex.bde.org> In-Reply-To: <1520215860.38056.3.camel@freebsd.org> References: <201803050156.w251u7Y8020941@repo.freebsd.org> <1520215860.38056.3.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Mar 2018, Ian Lepore wrote: > On Mon, 2018-03-05 at 01:56 +0000, Bryan Drewery wrote: >> >> Log: >> \xa0 chflags: Add -x option to not traverse mount points. > > Yay! \xa0One day later than I needed it, but still, yay! I recently noticed that find(1) needs an option to not look at mount points at all, and further options to classify mount points so that you can prune them. After reading the above and investigating further, I noticed that -x is broken in most FreeBSD utilities, since POSIX requires not looking at mount points at all for the few utilities that support -x. E.g., for du in 2001 draft 7 POSIX: 12578 -x When evaluating file sizes, evaluate only those files that have the same device as 12579 the file specified by the file operand. 12580 Specifying more than one of the mutually-exclusive options -H and -L shall not be considered Mount points are on a different device, but FreeBSD du -x is broken by using FTS_XDEV and not filtering out the mount points. Linux du -x (an old version in /compat/linyx/usr/bin) works correctly. (Elsewhere, POSIX uses the terms "mount point" and "file system" without specifying what they mean. E.g., for FTW_MOUNT which corresponds tp FTS_XDEV, it says "The walk does not cross a mount point". It is also unclear what "cross" means here -- the names of mount points are in the same file system although everything (?) else is in another file system. "mount point" should be specified as "a file whose device differs from the device of its directory", and "file system" should be specified as "all files on the system with the same given device". The latter allows the trees for file system to have weird topologies but is as good as anything. It is better than "all files under a mount point with the same device as the mount point". With the latter definition, given stat structs or even pathnames to 2 files, you would potentially have to walk all files starting at the root directory (if there is one) to determine if the 2 files satisfy the topological condtion of being under the same mount point.) FTS_XDEV is documented as doing the wrong thing for du -x by saying that it doesn't "descend" "into directories that have a different device number than the file from which the descent began". Its description of "same device" is too verbose. It would benefit from formally specifying mount points and file systems and "cross" too. Its "descent" is just good enough without a formal specification since the mount point is at level 0 in the new file system and a descent of 0 levels is not a descent in informal use (like for "negative", but unlike for ascent/positive where it is unclear if 0 levels is an degenerate ascent). The old POSIX draft uses "same.*device" just once according to a simple grep. This is the one quoted above for du -x. Old POSIX find doesn't even have -x. It has -xdev. This is strange, since FreeBSD's man page has said since long before 2001 that it is -xdev that is deprecated. It specifies -xdev using "descending", like for FTS_XDEV but with worse verbose wording. find(1) seems to be missing a classification option for mount points in both FreeBSD and POSIX. This could be used to prune mount points, but pruning is much harder than using a flag that works like -x should work. Perhaps something can be done with pruning levels for any utility that supports -x). E.g. -xx<number> could descend to N levels, where the level counter is set to 0 when a mount point is _first_ reached. Then -xx-1 would give the correct du -x behaviour of not doing the degenerate descent to level 0; -xx0 would give the find behaviour of doing the degenerate descent to level 0; -xx1 would descend 1 level; other positive descents are easy to implement; ther negative descents are too hard to implement. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180305140228.P935>