View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001997 | Issue 8 drafts | Shell and Utilities | public | 2026-08-16 17:33 | 2026-08-16 17:33 |
| Reporter | eggert | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | New | Resolution | Open | ||
| Name | Paul Eggert | ||||
| Organization | UCLA Computer Science Department | ||||
| User Reference | mvdownres | ||||
| Section | cp, mv, pax | ||||
| Page Number | 2744, 3199, 3257 | ||||
| Line Number | 90711–90712, 108114–108115, 110301–110302 | ||||
| Final Accepted Text | |||||
| Summary | 0001997: cp,mv,pax should not need to diagnose timestamp downresing | ||||
| Description | When the command ‘mv /a/SOURCE DEST’ crosses file system boundaries, the resulting file DEST can have a timestamp with less low-order information as described by futimens (POSIX.1-2024 page 1075 lines 36821–36822). For example, the source file’s timestamp might be 1786900895.478636836 but the destinations might be on a FAT32 filesystem so its timestamp might be only 1786900895.47, as FAT32 has only 10 ms resolution. This topic recently came up in a bug report for GNU mv <https://bugs.gnu.org/13601#40>. One commenter there said that this loss of information triggers the clause for mv (page 3199 lines 108114–108115) saying “If the duplication of the file characteristics fails for any reason, mv shall write a diagnostic message to standard error” which means a diagnostic is required. GNU mv, and I expect all other mv implementations, does not do that. Instead, it uses futimens or utimensat to set DEST’s timestamps, and if that succeeds it does not issue a diagnostic. Checking whether DEST’s timestamp lost low-order info would require another system call, and I don’t know of any mv implementation that does so. A clarification is needed here for the phrase “duplication of the file characteristic fails for any reason”. Does the phrase mean that (a) a system call like futimens failed, or does it mean that (b) the destination’s characteristics disagree, even slightly, from the source’s? Although implementations have chosen (a) POSIX could be read as requiring (b). If an implementation wanted to implement (b), for efficiency it would be helpful if utimensat acquired an additional flag to cause the system call to fail if the timestamp is downresed. However, that would be a separate topic from this bug report, and I know of no platform that has such a flag so at this point it would be pure invention on the POSIX committee’s part. In the DESIRED ACTION I have attempted to word things so that an implementation can do either (a) or (b). (b) is allowed because an implementation can always issue a diagnostic whenever it likes, so long as it does not change the exit status. | ||||
| Desired Action | cp page 2744 lines 90711–90712. After “If this duplication fails for any reason, cp shall write a diagnostic message to standard error.”, append “Duplication of timestamps means that the destination file's relevant timestamp is set to the greatest value supported by the file system that is not greater than the source file's, and timestamp duplication does not fail merely if these two values disagree.” mv page 3199 lines 108114–108115. Similar change. pax page 3257 lines 110301–110302. Similar change. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-08-16 17:33 | eggert | New Issue |
