ADSM-L

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

1996-09-02 09:53:41
Subject: Re: ADSM Backup and its alteration of file "last access" timestamp
From: Michael Fink <Michael.Fink AT UIBK.AC DOT AT>
Date: Mon, 2 Sep 1996 15:53:41 +0200
On Tue, 27 Aug 1996, Richard Sims wrote:

> An historic problem with ADSM Backup is its alteration of a file's
> "last accessed" timestamp, which is highly undesirable, particularly in
> the case of mail files where handling programs detect unread mail via
> "modified" and "accessed" timestamps.  This is also a privacy and
> security issue.
>     I scanned the ADSM-L archives to review past discussions of this
> issue.  It has been the subject of customer complaints, but as yet seems
> to have no resolution.  One circumvention I've considered it to mount the
> subject file system a second time on the client, at a different mount
> point, in read-only mode, and then perform the ADSM backup.
> But I'd like to see a more natural solution to this problem from IBM.
>     So I seek whatever perspectives list members have on this.
>          thanks,   Richard Sims, Boston University OIT

I'm a bit surprised that there has not been any echo on this letter
so far. Either it has been discussed /ad nauseam/ previously
(I'm relatively new to the list) or it's not an issue or (I hope not)
there are so many issues more urgent than this one...?
Anyway, I plainly second above views.

As a matter of definition, a backup/restore system is supposed to
take a snapshot of the information in a file system and to be able
to restore this information when needed. In a UNIX file system, the
information consists of all files' data and metadata. A backup system
that alters this information will not be able to fully restore it.

If a feature such as atime exists in a system, it will be used for
various (unforseeable) purposes; detecting unread email is just one
example. So if you alter atime by backup procedures, you will break
an unknown number of applications or - at the least - confuse users
who try to interpret the output of the `ls -lu' command.

Taking this evident principle into account, traditional UNIX backup
methods have either avoided updating the atime alltogether by directly
accessing the inode area (dump(1M) being an example) or have provided
options to reset the access time after copying out the files
(such as tar(1), cpio(1) etc.).

So why go for less? It's easy to implement, anyway. Just look into
any PD version of tar or cpio and imitate their work. Hey IBM
folks, what're you waiting for? (And then, for a real improvement,
please add backup of special files, too.)

Sincerely,

   Dr. Michael Fink +-----------------------------+------------------------
        EDV-Zentrum | Universitaet Innsbruck      | Tel: +43(512)507-2311
 Computing Services | Technikerstrasse 13         | FAX: +43(512)507-2944
--------------------+ A - 6020 Innsbruck, Austria | Michael.Fink AT uibk.ac DOT 
at
=========================================================================
<Prev in Thread] Current Thread [Next in Thread>