Path: utzoo!attcan!uunet!lll-winken!ames!ncar!noao!asuvax!nud!estinc!fnf
From: fnf@estinc.UUCP (Fred Fish)
Newsgroups: comp.unix.wizards
Subject: Re: GNU-tar vs dump(1)
Message-ID: <15@estinc.UUCP>
Date: 14 Jan 89 17:36:04 GMT
References: <17999@adm.BRL.MIL> <629@mks.UUCP> <11@estinc.UUCP> <10797@rpp386.Dallas.TX.US> <1966@netmbx.UUCP> <6099@polya.Stanford.EDU>
Reply-To: fnf@estinc.UUCP (Fred Fish)
Organization: Enhanced Software Technologies, Inc.
Lines: 55

In article <6099@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes:
>One thing that worries me about using tar for dumps is that it updates
>the access time of all the files that it reads.  Is there any way to
>avoid this?

Yes, it is possible, but it has other side effects that are undesirable.
One of the unavoidable warts of UNIX backup utilities that operate through
the normal user interface to the filesystem (as opposed to filesystem
specific utilities like "dump" that go directly to the raw filesystem)
is that it is impossible to independently set (backdate) all of the
times associated with a particular file.  Below is one of the "design
notes" files I include in the bru source distribution:

#include notes/ctime...

For several years, bru only looked at the mtime field in the stat(2) structure
to decide if a file had been modified.  This worked fine for files which had
their contents modified, but did nothing for files that had only their
attributes changed, such as with chmod(1), chown(1), etc.  Since the ctime
field was ignored, we could use the utime(2) system call to reset the
atime fields whenever we merely read a file to back it up.  This allowed
us to preserve ALL the time fields except for ctime.

However, it was finally decided that ignoring ctime was the wrong thing to
do, and that bru should look at the most recent of mtime or ctime to determine
the "modification date".  Thus if either the file or it's attributes changed,
the file would be backed up.  In the case of only the attributes changing,
backing up the entire file is overkill, but not harmful.  Although some files
without contents are stored in bru archives (such as directories and FIFO's)
it is not possible to store just the attributes of a normal file using the
current format.  This was a design oversight.

No longer ignoring ctime has one mandatory side effect in the way bru 
operates.  We can no longer use utime(2) to reset the atime and mtime
fields after merely reading a file.  In effect, the "-a" command line
option now is permanently set, as the calls to the routine to reset these
times has been removed from the bru source (although the routine itself
has been kept around temporarily, just ifdef'd out).

The original idea behind preserving atime was to allow migration of files
to offline storage if they had not be accessed in any "meaningful" way
recently.  Simply backing up the system was not considered to be a 
meaningful access, so the atime field was preserved.  In actuality,
no program that the author currently knows about performs migration or
deletion based on the atime field.  In fact, the filesystem management
system currently under development by the author of bru will ignore
the atime field also.  It will base it's file migration or deletion
actions on other criteria.

#end notes/ctime

-Fred
-- 
# Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284,  USA
# asuvax!nud!estinc!fnf