0001776: find -newer any symlinks - Austin Group Defect Tracker

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Category

Severity

Type

Date Submitted

Last Update

0001776

[Issue 8 drafts] Shell and Utilities

Objection

Error

2023-09-29 15:07

2023-12-07 14:10

Reporter

stephane

View Status

public

Assigned To

Priority

normal

Resolution

Accepted As Marked

Status

Applied

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

0001792

Resolved

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

Mantis 1.1.6[^]