On Tuesday 17 March 2015, Karel Zak wrote: > On Tue, Mar 17, 2015 at 06:14:00PM +0100, Ruediger Meier wrote: > > On Tuesday 17 March 2015, Karel Zak wrote: > > > On Tue, Mar 17, 2015 at 04:08:58PM +0100, Ruediger Meier wrote: > > > > Hi, > > > > > > > > I wonder what is the correct way to find a mount which is > > > > mounted to a certain target directory. findmnt --target will > > > > also find a mount if you specify a subdirectory of a > > > > mountpoint: > > > > > > > > $ mkdir /tmp/bla > > > > $ findmnt --target /tmp/bla > > > > TARGET SOURCE FSTYPE OPTIONS > > > > /tmp /dev/mapper/vg0-tmpdirs[/tmp] ext4 .... > > > > > > > > The man page let me think that --target should not find the > > > > parent directory. > > > > > > No, it's expected behavior since: > > > > > > commit b215d8e9a71ca8d22df6111ddc9d28bd896febb1 > > > Author: Dave Reisner <dreisner@xxxxxxxxxxxxx> > > > Date: Wed Apr 25 20:30:52 2012 -0400 > > > > Ok, but this was a regression for a common use case. I guess to > > late to revert. Even you liked this old behavior: > > Well, the common use-case is to not use --target :-) Yes, but somehow I find the default mix of source and target odd. For arbitrary unknown files I would never use it without --target or --source. BTW this kind of smart interpretation of input arguments is something I really hate. I just played around with file names like "253:0" or "LABEL=bla" as device nodes or mountpoints. IMO it's horrible ... maybe even a security issue ... thinking about placing such files or (symlinks!) into /tmp and wait until root is there when he invokes findmnt. Example: $ touch "253:0" $ truncate -s 10 bla $ sudo mount --bind bla "253:0" $ findmnt --target "253:0" TARGET SOURCE FSTYPE OPTIONS /home/rudi/devel/util-linux/build/253:0 glaukos:/exports/home/rudi/devel/util-linux/build/bla nfs4 rw,... $ findmnt "253:0" TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/vg0-root ext4 rw,relatime,data=ordered Shouldn't the last command also find all mounts with mountpoint "./253:0"? > But I agree that > the feature is questionable. The mistake is that the original > (non-df) behavior has not been covered by test. > > > commit 1f42e1089aadbe537bb59143502ebd1767d3f7ea > > Author: Karel Zak <kzak@xxxxxxxxxx> > > Date: Sun Jan 2 22:56:31 2011 +0100 > > > > tests: use findmnt(8) for mount --move test > > > > > and the current git tree contains: > > > > > > -T, --target path > > > Explicitly define the mount target (mountpoint > > > directory). If the path is not a mountpoint file > > > or directory than findmnt checks path elements in > > > reverse order for get the mountpoint (this > > > feature is supported only if search in kernel > > > files and unsupported for --fstab). > > > > Ah ok, but IMO because of this regression we should make it even > > more clear. Probably the first sentence should not contain "mount > > target" and "mountpoint" without also using the term "parent > > directory" or similar. > > > > I think for df(1) it's written nicely: > > > > df [OPTION]... [FILE]... > > Show information about the file system on which each FILE > > resides, or all file systems by default. > > OK. > > > > > $TS_CMD_MOUNT --move $DIR_A $DIR_B > > > > > > > > # check the move > > > > $TS_CMD_FINDMNT --kernel --target "$DIR_B" &> /dev/null > > > > [ "$?" == "0" ] || ts_die "Cannot find binded $DIR_B" > > > > [...] > > > > > > > > This findmnt line will never fail I guess. > > > > > > Right, this is mistake, solution is to remove --target: > > > > > > TS_CMD_FINDMNT --kernel "$DIR_B" &> /dev/null > > > > > > > > > The disadvantage is that without --source/target findmnt(8) tries > > > to use the path as source and then as target. It's bad in same > > > cases. > > > > > > Maybe we need a new option to disable the evaluation of the > > > target path elements. (--strict-target) > > > > What about "findmnt --target /bla/xyz --no-parents" instead > > of --strict-target? > > No problem. I'm still not 100% sure. Now I think --mountpoint could be nice to change the current short usage from this: findmnt [options] <device> | <mountpoint> findmnt [options] [--source <device>] [--target <mountpoint>] to this: findmnt [options] <source> | <mountpoint> findmnt [options] [--source <source>] [--target <file>] [--mountpoint <mountpoint>] ... without changing current behavior. Moreover we could add "--parent" so that "--mountpoint --parent" would do the same like "--target" does now. Just keeping --target for compatibility. Maybe even set --target deprecated and remove it from short usage documentation. > > I have to admint that I don't really like the current behavior > > of --target and the default case without --source/target. Of course > > we can't change it anymore. > > Yes, after 3 years it's better to keep the current behavior and > provide an option to disable the "smart" target evaluation. Do you > want to send a patch? (or I can do that tomorrow.) Please go ahead, I guess I would need much more time for this. cu, Rudi -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
