bane@parcvax.Xerox.COM (John R. Bane) (06/09/87)
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. Thanks in advance... -- Rene P.S. Bane bane.pa@xerox.ARPA ...!parcvax!bane.UUCP
apratt@atari.UUCP (Allan Pratt) (06/10/87)
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 \----------------------------------------------/
nowlin@ihuxy.ATT.COM (Jerry Nowlin) (06/11/87)
In article <756@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > The archive bit is bit 5 (0x20) in the file attributes. Directories > (folders) don't have a useful archive bit. So far I've ignored the fact that the date and time of folders don't seem to make sense. Now that someone's mentioned that folder attributes aren't the same as plain files I thought I'd ask about the time stamp problem. What exactly can you do with the information that you get about folders from GEMDOS? Are the name and extension the only things that are usable besides the attribute that says it's a folder? Jerry Nowlin (...!ihnp4!ihuxy!nowlin)
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (06/12/87)
I would basically agree with previous comments. With current versions of GEMDOS on the ST, the archive bit doesn't work. If you assume that it works opposite to how it's supposed to you can get away with it a lot of the time, but not perfectly (and in fact that is what "BackUp!" from Michtron (which I wrote) does). If and when a rewritten version of GEMDOS appears I'll release an update to "BackUp!" to handle it correctly. I would presume that the author of Turtle and any other backup systems that currently use the archive bit would do the same. dgc
woodside@ttidca.UUCP (06/15/87)
In article <756@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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. ...[omission of Allan's backup program idea...] >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. Yes, that's the opposite of what TURTLE is expecting. Since the documentation in Hitchhiker's Guide was not too clear, I tested the bit to see what was happening with it, then wrote TURTLE to deal with it as it was used. I then did backups, setting the archive bit, and incrementals, reading it. It did select the updated files, and all new files. If the promised new ROMs will actually implement the Archive bit as Allan describes, I'll make a provision in TURTLE to deal with it. On the topic of postings, TURTLE is ready and waiting for the re-appearance of the binaries group. The current version is always on Compuserve, in the Atari-16 SIG. I am joing GEnie, and will be posting it there, if the version there is not up-to-date. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. ..fooling rn.. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{trwrb|philabs|csun|psivax}!ttidca!woodside
hmm@laura.UUCP (06/17/87)
In article <1994@ihuxy.ATT.COM> nowlin@ihuxy.ATT.COM (Jerry Nowlin) writes: >So far I've ignored the fact that the date and time of folders don't seem >to make sense. Somehow, GEMDOS does not byte-swap the timestamps for folders. So they are in 68000 byte order, while all other stuff on the disks are in 8086 byte order (for MessDOS compatibility). I have reported this bug to Atari back in those good old days when TOS weren't burnt in ROMs, but obviously no one heard me :-( Since you don't need this stuff anyway, just ignore it... Greetings, Hans-Martin <hmm@unido.uucp>, <hmm@unido.bitnet> D