|Anonymous | Login||2018-07-16 22:30 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001133||[1003.1(2016)/Issue7+TC2] Shell and Utilities||Objection||Clarification Requested||2017-03-27 10:27||2017-03-29 13:48|
|Final Accepted Text|
|Summary||0001133: find clarification on -xdev behavior for mounted filesystem within primary|
Current find description for -xdev:
The primary shall always evaluate as true; it shall cause find not to continue descending past directories that have a different device ID (st_dev, see the stat() function defined in the System Interfaces volume of POSIX.1-2008). If any -xdev primary is specified, it shall apply to the entire expression even if the -xdev primary would not normally be evaluated.
-xdev definition do not have a unique understanding from OS implementation on how to deal with filesystem mounted within primary, Solaris find and GNU find are currently behaving in different way.
Both should be POSIX standard compliant, therefore the same behavior is expected.
It has to be clarified if that mount point itself has to be listed or skipped, by POSIX definition.
It is important to recall that the mount point itself have a different st_dev then primary (see evidence below).
Consider the following example, with mountpoint on /mnt/testmount
root@testserver:~# pkg info entire
Summary: entire incorporation including Support Repository Update (Oracle Solaris 188.8.131.52.0).
Version: 0.5.11 (Oracle Solaris 184.108.40.206.0)
Build Release: 5.11
Packaging Date: June 10, 2016 12:51:48 AM
root@testserver:~# zfs list /mnt/testmount
NAME USED AVAIL REFER MOUNTPOINT
rpool/mounttest 31K 46.2G 31K /mnt/testmount
root@testserver:~# find /mnt -xdev -type d
testserver ~ # uname -a
Linux testserver 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux
testserver ~ # rpm -qf /usr/bin/find
testserver ~ # df|grep test
/dev/mapper/myvg-mounttest 999320 2572 927936 1% /mnt/testmount
testserver ~ # find /mnt/ -xdev
testserver ~ #
testserver ~ # stat /mnt/|grep Device
Device: fd01h/64769d Inode: 8196 Links: 3
testserver ~ # stat /mnt/testmount/|grep Device
Device: fd07h/64775d Inode: 2 Links: 2
testserver ~ #
So the Device ID is different (fd01h/... vs fd07h/...), as expected.
The core is the following sentence:
"it shall cause find not to continue descending past directories that have a different device ID (see st_dev"
1) clarify which of the two behavior is technically correct, to list or skip the mount point itself
2) Have a more clear statement for -xdev find XCU definition
Given all of the above skip of the mount point seems the correct behavior, as different ID is listed.
If confirmed, to fix #2, the following rewording is suggested:
The primary shall always evaluate as true; restricts the search to the directory with the same device ID of primary (st_dev, see the stat() function defined in the System Interfaces volume of POSIX.1-2008). If any -xdev primary is specified, it shall apply to the entire expression even if the -xdev primary would not normally be evaluated.
|Tags||No tags attached.|
As a logical entry in the directory of the device where the find traversal begins, I'd expect when -xdev is set a mount point name to be listed similar to symbolic links when neither -H or -L are specified, as the intent of the wording. That the st_dev of the mount point target differs does not affect the mount name entry in this regard. When -H or -L are specified with -xdev, I'd expect a symbolic link target with a mount point reference to a different st_dev in any part of the substitute path to keep that symbolic link from being part of the output, but not a direct mount name.
However, a mount need not have an actual physical file entry stored on the media, of any standard or implementation-defined file type as its inode target. If the implementation maintains a separate table of mount points, and checks each open() or creat() attempt, and symbolic link resolutions, against that table and the stored dirents for name collisions, the find implementation may simply be limiting itself to the entries on the media when -xdev specified. A name in the table would not be part of the output then.
Either behavior I could see being construed as conforming. The standard does not require st_dev values be stored in FILE records on media; they're usually synthesized in some manner for stat() calls as something configuration dependent, not static values that could be considered portable. In terms of resolving the ambiguity, I can see making it a requirement mount names show when
neither -H or -L specified, whether -xdev set or not, and hidden when either option and -xdev is specified, treating the direct name as a symbolic link body, essentially. This may be a breaking change, but covers both observed behaviors.
edited on: 2017-03-29 13:49
SVSvr4 and descendent find implementations
Schily find (sfind) which is based on libfind
do not list mount points that return a different st_dev with stat(2).
This does not include possible mount points that are currently not mounted
but it applies to all mount points that are currently mounted.
|2017-03-27 10:27||Rocco83||New Issue|
|2017-03-27 10:27||Rocco83||Name||=> Daniele Palumbo|
|2017-03-27 10:27||Rocco83||Section||=> find|
|2017-03-27 10:27||Rocco83||Page Number||=> -|
|2017-03-27 10:27||Rocco83||Line Number||=> -|
|2017-03-27 19:11||shware_systems||Note Added: 0003654|
|2017-03-29 13:48||joerg||Note Added: 0003656|
|2017-03-29 13:49||joerg||Note Edited: 0003656|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|