mph@rover.UUCP (Mark Huth) (08/07/87)
I have completed the initial development of a hard disk backup program. I feel that there is a need to define an additional bit in the protection field of the file attributes. While there is no problem in commandeering a bit and using it in the program and then writing a utility to set it, I would rather get CA's or at least this forum's blessing, so as not to interfer with other uses of the protection field. The bit that I propose would be set to indicate that the file should not be backed up. This, of course, can be done with the archive bit, but the archive bit has a somewhat different meaning. The archive bit is cleared upon file update, and would have to be explicitly set for files that are temporary after each use. The "NOBACKUP" bit, one the other hand, would allow one to flag the T: directory so that any files therein would not be backed up. Also, the many PD directories which I keep on my hard disk would all be flagged, since the copies are backed up on the floppies from whence they came. By flagging a directory, the backup program would avoid the search through each file for protection attributes. This should greatly speed the process of backing up a hard drive without the need to write elaborate scripts. For lack of a better starting point, I propose to use 0x00000200 (bit 5, the sixth bit, the one just more significant than the archive bit). Please respond via email and I will post the consenses. If CA wishes to make a decree on this issue, please post to the net. Thank you, Mark Huth - I speak for myself seismo!noao!mcdsun!nud!rover!mph
andy@cbmvax.UUCP (Andy Finkel) (08/10/87)
In article <461@rover.UUCP> mph@rover.UUCP (Mark Huth) writes: >I have completed the initial development of a hard disk backup program. I feel >that there is a need to define an additional bit in the protection field of the >file attributes. While there is no problem in commandeering a bit and using it >in the program and then writing a utility to set it, I would rather get CA's or >at least this forum's blessing, so as not to interfer with other uses of the >protection field. > Please use one of the bits in the range 24-31 (the top 8). The others are reserved, and have destinies in future releases of the operating system. The top 8 are reserved for application programs. I'll maintain a list of which bits which applications use (if people tell me). I do suggest that you make the bit user definable, though, in a configuration file, just in case. thanks, andy finkel -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "The goal of Computer Science is to build something that will last at least until we've finished building it." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
daveh@cbmvax.UUCP (Dave Haynie) (08/11/87)
in article <461@rover.UUCP>, mph@rover.UUCP (Mark Huth) says: > Keywords: protection, backup > > The bit that I propose would be set to indicate that the file should not be > backed up. ... The "NOBACKUP" bit, one the other hand, would allow one to > flag the T: directory so that any files therein would not be backed up. Certainly, in the current release of the OS, you could achieve much the same effect by clearing the read access bit of a file. The OS itself ignores this bit, but there's no reason you have to. It would be reasonable for a backup utility to pay attention to this bit anyway, so a file without read access isn't backed up, and nothing in a directory without read access is backed up. The only problem this might cause is if other programs also pay attention to the setting of this bit and require you to change the bit before they'll read it. I don't know who would be looking at this bit in that way, as it really is the OS's job to detect the read protect bit and refuse a program Lock() or Open() access to that file. If the OS is upgraded to a state that starts honoring the read protect bit, it may very well be upgraded to provide a formal don't-archive-me method as well. I know Andy's gang is making plans for future protection bit designations. But until then, it's dangerous to start using reserved protection bits. > Mark Huth - I speak for myself -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "Catch a wave and you're sittin' on top of the world" -Beach Boys
mph@rover.UUCP (Mark Huth) (08/12/87)
Okay, thanks, Andy. I hereby state that our backup program will use bit 24 as the NOBACKUP bit. When set (I'll provide the utitilty) the Jefferson Enterprises backup program will not include the file (or directory tree) in the backup list. Of course, now we need a list that will display this status! Mark Huth seismo!noao!mcdsun!nud!rover!mph