On Mon, 25 Aug 2008 11:25:47 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Well, from a FAT standpoint, I doubt anyone can say the archive bit is
>> "bolted on the side".
> 
> True. On the other hand, the original FAT file system had the semantics
> of the CP/M file system. But yes, by the time it got to the point where
> you actually did backups and had temp files you left hanging around, the
> archive bit was pretty well established. 

True.

> That MS's own programs didn't
> mark things as "don't archive this" (and that it really isn't a "don't
> backup" bit but more a "don't incrementally back up" bit) didn't help.

I do recall that MS' DOS-based backup utility (I forget what it was 
called) did actually observe the archive bit.  The apps didn't use it 
often enough, though; it was typically used by the backup utilities to 
flag that a file had been archived by a backup system, not as a means of 
skipping files you didn't want backed up (but a little creative thinking 
would've come to the conclusion you could use it for both).

>> Maybe what needs to happen is for programmers to use what's there
>> rather than invent something else for them to ignore, though
> 
> Pretty much anything that isn't lowest-common-denominator is going to
> get ignored by the majority, I expect.  That's why it would be nice if
> the bit actually got by-default inherited by files inside directories
> with the bit set. Then you could set that bit on (say) /tmp and be done
> with it.

True.  And I agree it would be nice if it recursed; considering the speed 
of computers of the day, though, I wonder how practical it would've been 
to implement - true you could do a dynamic evaluation, but MS so likes 
doing the "traverse and stamp every object", as evidenced by the horribly 
broken behaviour in AD version 1 when assigning rights through a 
filesystem.   Thank goodness they fixed that behaviour.

Jim

Post a reply to this message