On Thu, May 16, 2024 at 5:33 AM Walter Alejandro Iglesias
<w...@roquesor.com> wrote:
>
> 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.
...
> 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.
So you did so and then checked the timestamps on the symlinks using
stat to see how they compared, yes?
> Now pax (with your patches) doesn't
> insist in re-updating the file,
Sounds like you copied with something like 'cp -p' so the copy has a
mtime with zero nsecs part, so now they do compare as equal.
> *even after updating the file with
> touch(1)*.
Why would the symlink needs to be recopied by pax? You didn't update
the symlink's timestamps.
> The soft link *still* points to a location with high-precision
> timestampts, but pax does the right job.
Because the symlinks now have the exact same timestamp, one with zero nsecs.
> Intuitively this suggests me that there is something more that mtime
> precision in this misunderstanding between OpenBSD and ext2 file
> systems.
I think you should check the timestamps on the symlinks at each step
to validate that.
> 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.)
The released install tgz files (base75.tgz, etc) use a format where
the contained files all have simple integer mtimes and tar is invoked
with the -p option (required for correct permissions on setuid/gid
files) which makes it also set the mtime on the extracted file to
match what's in the tar file.
ctime is always set from the local clock when the inode is
allocated/updated, so no reason for it to always have a zero nsecs.
atime is of course updated from the local clock when you, uh, access them.
Philip Guenther
