On Fri May 17 09:50:58 2024 Philip Guenther wrote: > 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.
This morning I realized that when I copied the symlink from the ext2 drive to my hard disk, cp(1) didn't copy the symlink but the executable itself. Reading cp(1) man page I see that the command I should have used to copy the symlink is 'cp -PR'. In my case caffeine is affecting negatively, it makes me jump to conclusions. Sorry for make you waste your time! > > > > P.S.: I'm curious 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. Thanks for your explanation! > > > Philip Guenther > > Walter
