On Thu, 17 Jan 2008, Tom Lane wrote:
> BTW, is a symlink's atime changed by accessing it?
It seems so in the cases I've tried or researched, but it's complicated.
After burning through a bunch of time looking into this I wanted to drop
some notes so nobody else has to wander down the specific dead-ends I just
followed.
I figured I'd just run some experiments to figure this out for my Linux
system, but that didn't go so well. The process of running anything that
shows the atime:
ls -l --time=atime <file>
ls -lu <file>
stat <file>
actually updates the atime to right now along the way. I hacked up
something with perl that directly calls lstat() and it did the same thing.
Mystified, I found this thread suggesting the same thing is true on Mac OS
X: http://lists.apple.com/archives/darwin-kernel/2006/Dec/msg00054.html
The point made in there is that how symlinks are encoded varies not just
from OS to OS but from filesystem to filesystem, and that encoding changes
how things like atime work. On Linux with ext2, I found this note:
"Symbolic links are also filesystem objects with inodes. They deserve
special mention because the data for them is stored within the inode
itself if the symlink is less than 60 bytes long. It uses the fields
which would normally be used to store the pointers to data blocks."
So what I think is happening is: the process of doing anything at all
with a Linux symlink references the inode that has the link. That updates
the atime on that inode. But since there's no actual data underneath that
lookup in cases where the link is less than 60 bytes, the inode atime is
the link atime, so that just updated the link's atime to right now as
well. I have no idea how any tmp cleaner could ever find a short symlink
it can delete if I'm understanding this correctly.
I left behind the link I was just playing with and I'll see if I can get
tmpwatch to eat it tomorrow, that seems like the most appropriate test
here.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD