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
	   permissions.
	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.