Anonymous | Login | 2024-12-12 12:51 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | ||||||
|
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 |