View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001776 | Issue 8 drafts | Shell and Utilities | public | 2023-09-29 15:07 | 2024-06-11 09:12 |
| Reporter | stephane | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Closed | Resolution | Accepted As Marked | ||
| 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 | 0001776: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 | ||||
| parent of | 0001792 | Resolved | Example 7 needs to use find's -H option |
|
|
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. |
| 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 | => 0001776: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 |
