Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdcad!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Archive bit?
Message-ID: <756@atari.UUCP>
Date: Wed, 10-Jun-87 13:43:11 EDT
Article-I.D.: atari.756
Posted: Wed Jun 10 13:43:11 1987
Date-Received: Sat, 20-Jun-87 05:38:33 EDT
References: <343@parcvax.Xerox.COM>
Organization: Atari Corp., Sunnyvale CA
Lines: 48

in article <343@parcvax.Xerox.COM>, bane@parcvax.Xerox.COM (John R. Bane) says:
> 
> I've heard that somewhere in the depths of the ST file system there is a
> 1-bit flag for each file on a device which can be used by backup programs
> (i.e., backup programs set it when they backup a file, and writing the file
> unsets it). Is this true, and if so, where is it? My current guess from
> reading the crufty Abacus docs is one of the high order bits in the file
> mode byte.

Yes, there is such a bit, but, alas, it is not correctly maintained by
the current GEMDOS.

In theory, the bit is set when a file is written to and closed, and
cleared (by the backup program) when the file is backed up.  This
behavior lets the backup program determine which files have changed
(or are entirely new) since the last backup.

In practice, the bit is nondeterministic when the file is written to and
closed.  What's worse, the time stamp isn't changed (the current time
stamp is the CREATION time, not the LAST-MODIFIED time).  If you set or
clear the bit manually, and don't change the file, it will stay set or
clear. 

What I have considered for some time is a backup program which keeps a
record of the date it was last run.  All archive bits on files before
that date are assumed to be correct (set=new or clear=old), and files
after that date are assumed new.  When the program runs, it clears the
archive bits of files it backs up, and sets the archive bits of "new"
files it doesn't back up.  When it's done, it updates its "last run"
date, so next time it will know the cutoff date for valid archive bits. 

This scheme will work with files you change with Emacs (which deletes
the old file and creates a new one when it saves) or the compiler (same
thing), but WON'T work with database files which are opened, changed,
and closed.  What you could do is manually set the archive bit of
these files after each archive.

Note that the theoretical behavior of the archive bit (and the way it
will work in a new, correct GEMDOS) is OPPOSITE to the behavior expected
by Turtle.

The archive bit is bit 5 (0x20) in the file attributes.  Directories
(folders) don't have a useful archive bit.

/----------------------------------------------\
| Opinions expressed above do not necessarily  |  -- Allan Pratt, Atari Corp.
| reflect those of Atari Corp. or anyone else. |     ...lll-lcc!atari!apratt
\----------------------------------------------/