I agree with Richard.  An atime/ctime option would be very valuable to
this institution.  I get complaints from my e-mail users continuously.

Ken Collop                      Internet: collop AT seattleu DOT edu
Systems Manager                 Phone:    (206) 296-5558
Seattle University              Fax:      (206) 296-5561
Seattle, WA 98122

On Tue, 11 Mar 1997, Richard Sims wrote:

> >is it possible to prevent ADSM from updating the access time
> >stamps (ls -lu) of the files during backup or archive?
> >It might be important for security reasons to check the
> >last access time of files, what will be useless if ADSM
> >updates it during a backup or archive session.
> >  Regards,
> >  Dirk Kastens
>
> Back on September 3rd, Stefan Steiner of IBM Almaden responded to
> user pleas on this issue.  Basically, ADSM *could* issue a utime()
> call to reinstate the file's original atime (access timestamp); but
> utime() causes the ctime (inode maintenance timestamp) to change.
> The IBM view was that for security purposes it is better to have the
> atime change than ctime.
>     For system-oriented files, I'd agree that it is better for atime to
> change than ctime.  However, ADSM is not intended for system files
> (can't handle Special files, etc.), and thus customers use ADSM primarily
> for backing up "user" data.  Users generally don't know what ctime is and
> don't care; but they are very sensistive to mtime (file modification
> timestamp) and atime.  And mail programs are sensitive to atime as their
> key to whether or not the user has read the mail recently.
>     So back in September I appealed to Stefan that ADSM should present
> customers with the choice (as options setting) as to whether ADSM access
> to files would update atime or ctime.  I am obviously just one of the
> customers yearning for that choice.
>     In the absence of that choice, we customers have to go through often
> horrendous machinations to avoid having the atime value updated by ADSM.
> Our intention of using ADSM for user backups has been delayed for months
> until I complete a subsystem which will perform an AIX logical volume
> copy of the user data volume to a backup volume group, mount that copy,
> and perform the ADSM backup from it.  It has been a tremendous amount of
> work, not to mention the overhead of doing such copies and then ending
> up with an unnatural filespace name.  (Unfortunately, under AIX, when a
> file system is mounted read-write, it is impossible to prevent file access
> from updating the atime, no matter what clever read-only remounting you
> attempt with the file system.)  The only other approach I see is an even
> more involved process of using the ADSM API to create your own ADSM backup
> program which will invoke utime() to restore the original timestamp.
>     In summary, we DESPERATELY need to have ADSM provide a choice in how
> timestamps are handled in ADSM backup.  The programming involved to
> implement such within ADSM would be relatively trivial, and it would mean
> so much to your customers, IBM.......please??
>          Richard Sims, Boston University OIT
>