Date: Mon, 5 Mar 2018 10:56:29 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Bryan Drewery <bdrewery@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Ian Lepore <ian@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: <201803051856.w25IuTid045284@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <8a8cd29b-9936-6d23-4e2b-4c646eca6aba@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 3/5/2018 8:37 AM, Bryan Drewery wrote: > > On 3/4/2018 8:30 PM, Bruce Evans wrote: > >> 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 > > > > Yes I'm quite annoyed that my workaround for chflags not having -x, > > using `find -x ... -exec chflags`, is still trying to modify mountpoints > > but not descending into them. > > > > Note of course my chflags change suffers the same problem of course > since it's just using FTS (these are null-mounted read-only or > devfs/procfs paths): > > > # /scratch/obj/root/git/freebsd/amd64.amd64/bin/chflags/chflags.full -Rx schg /poudriere/data/.m/exp-11amd64-commit-test/ref > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/distfiles: Operation not supported > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/compat/linux/proc: Operation not supported > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/proc: Operation not supported > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/dev: Invalid argument > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/rescue: Read-only file system > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/usr/tests: Read-only file system > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/usr/share: Read-only file system > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/usr/ports: Read-only file system > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/usr/src: Read-only file system > > chflags.full: /poudriere/data/.m/exp-11amd64-commit-test/ref/packages: Read-only file system > > Personally I find this behavior surprising and wrong and think all of > the tools -x[dev] behavior should not interact with these paths either > by default or with an option. Isnt part of the problem the directory under the mount point is technically a part of the parent file system, such that FTS is getting that, but then stating aginst the root of mounted directory? Would it be wrong to make it return the data for the hidden, and probably empty directory that is mounted over the top of, as technically that is part of the traversed file system. I also think this may be time for a change, especially in the zfs world of lots of datasets! > > >> > >> 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. > -- > Regards, > Bryan Drewery -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803051856.w25IuTid045284>