Since I'm mostly responsible for the atimes not getting reset, let me explain
the reasoning behind the decision:
1. UNIX (or at least historically) doesn't have a way to read a file
"invisibly", i.e. where the act of reading time file doesn't change file times.
This can be accomplished only if you unmount the read/write file system and
mount it read-only (or double mount the file system if your UNIX allows for it)
or after it is unmounted, go at the data directly in the disk partition.
2. Why not use utime(3)? The problem with utime() is that it only updates
atime and mtime. Another important, but less visible time, is ctime. ctime is
effectively the inode change time. When utime() is called, it updates ctime.
Example:
file: /usr/foo
atime: 2000000000
mtime: 1900000000
ctime: 1900000000 - note that when the filesystem automatically
updates atime, it does not update ctime
after running utime( "/usr/foo", times )
where the times structure contains:
actime = 1900000000
modtime = 1900000000
and the current time is: 2000001000
the effect of running utime will result in the times set for /usr/foo to
be:
atime: 1900000000
mtime: 1900000000
ctime: 2000001000
3. The view that ctime is more important than atime to keep accurate. This
point obviously is controversial. For security reasons, I would rather the
atimes get changed than the ctimes. An an administrator, I would worry when my
system files get their ctimes changed. Why? Because the files might have been
modified in some way by a hacker and to cover up the changes, she might have
updated the atimes and mtimes to their original values. This point, however,
might not have the same validity as it did in years past since many current
UNIX systems have other methods of tracking and preventing changes to certain
system files.
Please note that programs like gnu tar (when using the --atime-preserve flag)
and the like simply use utime() to update the times; therefore, they modify
ctime in their quest to preserve atime.
I do agree that the policy of not having a way to preserve atimes in ADSM needs
to be re-evaluated.
Stefan Steiner
IBM Almaden Research Center, San Jose
ssteiner AT almaden.ibm DOT com
|