On Thu May 16 09:48:45 2024 Philip Guenther wrote:
> So yeah, what's needed is pathconfat(2)** but whether this winding loose
> end ("That poor yak.") merits that much code and surface is yet to be
> examined deeply.
>
> Philip Guenther
>
>
> ** or lpathconf(2), but pathconfat(2) is better
>I read what you posted here: https://austingroupbugs.net/view.php?id=1831 In the footnote you wrote: "(This was encountered when trying to fix a pax implementation's handling of timestamp comparison for -u when the target filesystem had courser resolution that the source filesystem by using pathconf(_PC_TIMESTAMP_RESOLUTION) on the target path to handle the loss of high-precision time info...but the symlink pointed to a location with high-precision timestamps so it couldn't know to round the times when doing the comparison...)" I did one more experiment. I removed the offending soft link from my hard disk, then I copied the backed-up version of the soft link from the ext2 drive back to my system tree. Now pax (with your patches) doesn't insist in re-updating the file, *even after updating the file with touch(1)*. The soft link *still* points to a location with high-precision timestampts, but pax does the right job. Intuitively this suggests me that there is something more that mtime precision in this misunderstanding between OpenBSD and ext2 file systems. If I copy files using pax from Linux (another *BSD* version of pax) to that same ext2 drive it works as expected. Walter P.S.: I'm courious about the following. After running the stat command here and there, I found *many* files showing that lack of mtime granularity spread throughout all my system tree (as a side note: this doesn't happen with their ctime and atime.)
