Subject: file(1) resetting access times
To: None <tech-userlevel@NetBSD.ORG>
From: None <ghudson@MIT.EDU>
Date: 07/13/1995 00:02:21
file(1) tries to reset the access time of the file it reads. This has
at least four adverse effects when successful:
1. As pointed out by mycroft, resetting the access time
updates the inode access time, causing the file to be
backed up during the next incremental backup.
2. Resetting the access time causes the file to be copied up
if it's not in the top layer of a union mount.
3. It opens up race conditions if I read a file in between the
time file(1) reads the file and resets its access
4. If I want to know when a file was last read, I might get
inaccurate information (that is to say, the file might have
been read by file(1), which I might find interesting, but I
wouldn't be able to find this out).
Can anyone come up with any justification for this "feature"? It was
in the first revision of file.c in the CVS tree. If no one can come
up with a reason why anyone would want to be there, I'll just check in
a change removing the utime() code.