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