Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001776 [Issue 8 drafts] Shell and Utilities Objection Error 2023-09-29 15:07 2024-06-11 09:12
Reporter stephane View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed   Product Version Draft 3
Name Stéphane Chazelas
Organization
User Reference
Section find utility
Page Number 2920, 2924
Line Number 97596, 97747
Final Accepted Text Note: 0006578
Summary 0001776: find -newer any symlinks
Description The find specification has:

> -newer file
>
> The primary shall evaluate as true if the modification time of the current file is
> more recent than the modification time of the file named by the pathname file.

First maybe clarify that if relative, it's relative to the working directory at the time find was started.

That text doesn't say whether the modification time of "file" should be obtained before (lstat()) or after (stat()) symlink resolution, nor what should happen if that cannot be obtained, nor the effect of -L and -H in that regard.

What I find is that most implementations I've tried do a stat() on the file while GNU find does a lstat() unless -L/-H is provided (and the behaviour is clearly documented there).

All the ones I tried fail immediately with an error if the modification time of the file cannot be obtained and those that use stat() don't attempt a lstat() if stat() fails.

In implementations that do stat() it can happen that both:

find a -prune -newer b
find b -prune -newer a

print or don't print as find does a lstat() on the path operand and stat() on the reference file. For example, if "a" is a new symlink to an old file, "a" would be newer than "b" because find compares the age of the symlink with the age of "b" while "b" would also be newer than "a" because in that direction we compare the age of b with that of the old file "a" links to.

With -L/-H, the behaviour is consistent across implementations as stat() is performed on all files.

In any case, the example at line 97747 is incorrect without -H/-L as test's -nt compares files after symlink resolution (also note that the behaviour varies across test implementations when operand cannot be stat()ed).

IMO, GNU find's behaviour is better for the symmetry consideration and as it allows one to compare the age of symlinks. Having the possibility to chose between stat() and lstat() is also preferable for -samefile and -newerXY which POSIX might consider adding in the future.
Desired Action - clarify how pathname resolution is to be performed in case path is a relative path
- either specify the GNU find behaviour or leave it unspecified whether the mtime of the file is obtained before or after symlink resolution if -H/-L are not provided.
- clarify that it shall be an error if the mtime of the file cannot be obtained
- fix the example at line 97747 to use -H, and maybe add a "provided both file1 and file2 are accessible".
Tags applied_after_i8d3, tc3-2008
Attached Files

- Relationships
parent of 0001792Resolved Example 7 needs to use find's -H option 

-  Notes
(0006578)
geoffclare (manager)
2023-11-20 17:30

On page 2920 line 97596 section find (-newer), change:
The primary shall evaluate as true if the modification time of the current file is more recent than the modification time of the file named by the pathname file.
to:
The primary shall evaluate as true if the modification time of the current file is more recent than the modification time of the file named by the pathname file. If file names a symbolic link, the modification time used shall be that of the file referenced by the symbolic link if either the -H or -L is specified; if neither -H nor -L is specified, it is unspecified whether the modification time is that of the symbolic link itself or of the file referenced by the symbolic link. In either case, if the referenced file does not exist, the modification time used shall be that of the link itself. If file is a relative pathname, it shall be resolved relative to the current working directory that was inherited by find when it was invoked.

- Issue History
Date Modified Username Field Change
2023-09-29 15:07 stephane New Issue
2023-09-29 15:07 stephane Name => Stéphane Chazelas
2023-09-29 15:07 stephane Section => find utility
2023-09-29 15:07 stephane Page Number => 2920, 2924
2023-09-29 15:07 stephane Line Number => 97596, 97747
2023-11-20 17:30 geoffclare Note Added: 0006578
2023-11-20 17:31 geoffclare Final Accepted Text => Note: 0006578
2023-11-20 17:31 geoffclare Status New => Resolved
2023-11-20 17:31 geoffclare Resolution Open => Accepted As Marked
2023-11-20 17:32 geoffclare Tag Attached: tc3-2008
2023-12-07 14:10 geoffclare Status Resolved => Applied
2023-12-07 14:10 geoffclare Tag Attached: applied_after_i8d3
2023-12-18 18:45 Don Cragun Relationship added parent of 0001792
2024-06-11 09:12 agadmin Status Applied => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker