ADSM-L

Re: ADSM Backup and its alteration of file "last access" timestamp

1996-09-03 14:17:59
Subject: Re: ADSM Backup and its alteration of file "last access" timestamp
From: "Stefan R. Steiner" <ssteiner AT ALMADEN.IBM DOT COM>
Date: Tue, 3 Sep 1996 11:17:59 -0700
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
<Prev in Thread] Current Thread [Next in Thread>