SQ79@liverpool.ac.UK (Mark Powell) (08/09/89)
Bit 5 of a file mode is the archive bit. This is to do with backing up files.
When a file is backed up it's archive bit is set. When it is next written to
the bit is cleared. From this senario the disk back up program can tell whether
a file has been modified since the last back up and if so back up the file
otherwise leave it. This enables an incremental backup to be performed i.e.
back up your hard disk totally every month, and backup just the files that have
changed every week. Unfortunatley this procedure doesn't work on the old TOSes
(or so I'm informed) TOS 1.4 is said to fix this.
I have seen plenty of files on my disks with this bit set. You may be running
a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85
i.e. 20th November for you in the US who don't put the date in ascending or
descending order of significance (make your minds up!)
Mark Powell
ARPAnet : sq79%liv.ac.uk@{ucl-cs.arpa,cs.ucl.ac.uk}
USENET : ...!mcvax!ukc!liv.ac.uk!sq79wallace@oldtmr.dec.com (Ray Wallace) (08/11/89)
In article <8908091359.AA08065@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) writes... > > Bit 5 of a file mode is the archive bit. This is to do with backing up files. : > Unfortunatley this procedure doesn't work on the old TOSes : > I have seen plenty of files on my disks with this bit set. You may be running I forget the details on this but my understanding is that in most cases (ie: most programs that create/modify files) the archive bit is handled correctly. The problem with depending on the archive bit is that there are a few programs that modify existing files in such a way that the archive bit is not changed. --- Ray Wallace wallace@oldtmr.dec.com --or-- ...!decwrl!oldtmr.dec.com!wallace --or-- wallace%oldtmr.enet.dec.com --or-- wallace%oldtmr.dec@decwrl.dec.com (becoming obsolete) ---
alderaan@tubopal.UUCP (Thomas Cervera) (08/11/89)
In article <8908091359.AA08065@ucbvax.Berkeley.EDU> SQ79@liverpool.ac.UK (Mark Powell) writes: > > Bit 5 of a file mode is the archive bit. This is to do with backing up files. >When a file is backed up it's archive bit is set. When it is next written to > [...] I'm not sure but doesn't the archive bit indicate 'Dear backup program, I'm a file you should add to your archive because I was changed/created after the last backup' ? So, if backed up, a file's archive bit schould be clear -not set. My TOS 1.4 release DOES raise the archive bit on every file creation. One of my ATARI ST Programming Guides says that the archive bit will be set on every successful file creation/write access. -- Thomas Cervera | UUCP: alderaan@tubopal.UUCP SysMan RKOpdp (RSTS/E) | ...!unido!tub!opal!alderaan (Europe) D-1000 Berlin 30 | ...!pyramid!tub!opal!alderaan (World) Motzstrasze 14 | BITNET: alderaan%tubopal@DB0TUI11.BITNET (saves $$$)
towns@atari.UUCP (John Townsend) (08/15/89)
in article <8908091359.AA08065@ucbvax.Berkeley.EDU>, SQ79@liverpool.ac.UK (Mark Powell) says: > > > Bit 5 of a file mode is the archive bit. This is to do with backing up files. > When a file is backed up it's archive bit is set. When it is next written to > the bit is cleared. From this senario the disk back up program can tell whether > a file has been modified since the last back up and if so back up the file > otherwise leave it. This enables an incremental backup to be performed i.e. > back up your hard disk totally every month, and backup just the files that have > changed every week. Unfortunatley this procedure doesn't work on the old TOSes > (or so I'm informed) TOS 1.4 is said to fix this. > I have seen plenty of files on my disks with this bit set. You may be running > a different TOS from me though. I've got a UK TOS 1.0 dated 20/11/85 > i.e. 20th November for you in the US who don't put the date in ascending or > descending order of significance (make your minds up!) > You have it backwards. In TOS 1.4, the bit is set when a file is created or modified. The backup program should clear it after backing up the file. -- John Townsend Atari Corp.
covertr@force.UUCP (Richard E. Covert) (08/17/89)
In article <1651@atari.UUCP>, towns@atari.UUCP (John Townsend) writes: > > You have it backwards. In TOS 1.4, the bit is set when a file is created or > modified. The backup program should clear it after backing up the file. > > > -- John Townsend > Atari Corp. John, or Dan, I guess the first program every one writes is Yet Another Backup (YAB tm of CovertWares!!!). Anyway, I too am writing a very specific type of backup program. I had planned to use the READ/WRITE-READ/ONLY flag as a kind of backup flag. A un-backed up file would be RW but after I copy the file to floppy I would make it RO. That is because I was under the impression that TOS 1.0 and TOS 1.2 don't support a real backup bit. I have looked in my MWC manual (3.09) and there is no indiciation of a backup bit. Bit 5 (0x20) according to MWC in Fattrib() is "written and closed". I guess that could be used as a backup bit, but it isn't visible to the desktop. I normally use UIS2, and READ ONLY flags are shown with a check mark, so they become visible (at least with UIS2). That was the major reason why I was planning to use the READ/WRITE flag as a backup flag. Is there a better way?? richard (gtephx!covertr) covert
forcheck@rulcs.uucp (Jan Joris Vereijken) (03/27/90)
Dear ST'ers, Does anyone of you know of a program that will talk some sense into the archive-bit associated with every file? Probably you know what I mean: in MS-DOS (yuk!) this bit gets set every time the file is changed, and reset every time it is backed up. In that way incremental hard-disk backups become a snap. TOS unfortunalety doesn't do this... This is a real pain as I backup my SH204 using PC-SPEED & PC tools de Luxe (hey hey!). Sure works great, I even can optimize my TOS-partitions fine with a MS-DOS optimize tool :-) So, who can give me a pointer to this (preferrably auto-folder) program that I feel must exist somewhere? (btw: wasn't this cured in TOS 1.4?) Kind regards, Jan Joris Vereijken forchk@hlerul53.bitnet