Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter Rocco83 View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Daniele Palumbo
Organization
User Reference
Section find
Page Number -
Line Number -
Interp Status ---
Final Accepted Text
Summary 0001133: find clarification on -xdev behavior for mounted filesystem within primary
Description Current find description for -xdev:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html [^]
---
-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.
https://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating_systems [^]

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

Solaris 11.3:
root@testserver:~# pkg info entire
Name: entire
Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.9.4.0).
[...]
Version: 0.5.11 (Oracle Solaris 11.3.9.4.0)
Build Release: 5.11
Branch: 0.175.3.9.0.4.0
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
/mnt
root@testserver:~#

RHEL 7:
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
findutils-4.5.11-3.el7.x86_64
testserver ~ # df|grep test
/dev/mapper/myvg-mounttest 999320 2572 927936 1% /mnt/testmount
testserver ~ # find /mnt/ -xdev
/mnt/
/mnt/testmount
testserver ~ #

Again RHEL7:
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.
Desired Action 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"
sentence.

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:
---
-xdev
    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.
Attached Files

- Relationships

-  Notes
(0003654)
shware_systems (reporter)
2017-03-27 19:11

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.
(0003656)
joerg (reporter)
2017-03-29 13:48
edited on: 2017-03-29 13:49

SVSvr4 and descendent find implementations

.... and

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.


- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker