ADSM-L

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

1996-09-04 13:57:38
Subject: ADSM Backup and its alteration of file "last access" timestamp
From: Richard Sims <rbs AT BU DOT EDU>
Date: Wed, 4 Sep 1996 13:57:38 -0400
A thank-you to Stefan Steiner of IBM for explaining the rationale of
the ADSM Backup's current handling of the Access Time.
    I think the most obvious solution to this situation is to simply give the
customer the choice, via an option, as to whether a file system backup changes
the Access Time (atime) by taking no remedial action, or changes the Status
Change Time (ctime) by performing a utime() on the file.  The thought that
ctime is more critical and thus should be preserved is certainly the case for
opsys-oriented files, where preservation of ctime is important to security but
atime is not, given all the agents reading these files.  But in that ADSM
Backup handles only ordinary files, I doubt that most sites are using it for
opsys file systems: they are more likely using things like makesysb in AIX for
that purpose.  What ADSM will most heavily be used for is backup of user file
systems, and there it is atime which is more important to preserve, in that
users are naturally sensitive to others reading and writing their files.
Virtually no users know what the mysterious ctime value is about or care about
it, and in any case would probably expect various sysadmin functions to update
ctime if they were familiar with it.
    In short, then, give us the choice: give us some option or specification
to be associated with filespace names such that we can choose what is right
for us.  This should be relatively trivial to implement and, as evidenced by
feedback on this list, is in great demand.  To give you a sense of the need,
we are willing to serve as a beta test site for it.

  thanks,   Richard Sims, Boston University Office of Information Technology
<Prev in Thread] Current Thread [Next in Thread>