 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. 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.
> 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.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> I do recall that MS' DOS-based backup utility (I forget what it was
> called) did actually observe the archive bit.
All the backup utilities did (and do) pay attention to it. But the flag
automatically gets turned on whenever you open a file for writing, so
its use is primarily for differential backups. You do a full backup and
while doing so turn off the bit, then later you can back up just the
files with the bit set.
> 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).
It would only skip files you didn't want *incrementally* backed up. A
full backup would still copy the file, and there's no semantics (in UNIX
or Windows file systems at least) for "this is a temp file" sort of
thing, so don't ever back it up, or at least throw it away if you need
the room.
> 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.
That must have been a while ago. All the MS file systems I've ever
looked at had heritable privileges. (Given they had privileges to start
with, of course.) I'm not real sure where AD comes into it.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 25 Aug 2008 11:44:47 -0700, Darren New wrote:
> All the backup utilities did (and do) pay attention to it. But the flag
> automatically gets turned on whenever you open a file for writing, so
> its use is primarily for differential backups. You do a full backup and
> while doing so turn off the bit, then later you can back up just the
> files with the bit set.
Oh, right, I forgot about that bit with it getting reset when a file is
opened for writing.
> It would only skip files you didn't want *incrementally* backed up. A
> full backup would still copy the file, and there's no semantics (in UNIX
> or Windows file systems at least) for "this is a temp file" sort of
> thing, so don't ever back it up, or at least throw it away if you need
> the room.
Well, arguably, there is - you put it in /tmp - most programs do that.
Then you just exclude the directory from your backups.
> That must have been a while ago. All the MS file systems I've ever
> looked at had heritable privileges. (Given they had privileges to start
> with, of course.) I'm not real sure where AD comes into it.
Demonstration I saw showed it pegging the CPU at 100% for nearly 40
minutes because the rights were stamped on each object. Come to think,
it wasn't the filesystem - it had to do with assigning rights in AD
itself, not to the filesystem. It's been a few years.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Well, arguably, there is - you put it in /tmp - most programs do that.
> Then you just exclude the directory from your backups.
Well, yes, but programs don't do that. KDE doesn't put the fingernails
there. Firefox doesn't put the cache files there. Thunderbird doesn't
put the index files there. VI doesn't put .swp files there. Etc.
Basically, anyone who doesn't want to have to pick an arbitrary name and
then somehow relate it back to the file it's related to isn't going to
put it in /tmp/. And /tmp really isn't where you want to store all that
stuff anyway, or you'll wind up filling up whatever partition /tmp is
on, which is usually smaller than the partition your home directory is on.
> Demonstration I saw showed it pegging the CPU at 100% for nearly 40
> minutes because the rights were stamped on each object. Come to think,
> it wasn't the filesystem - it had to do with assigning rights in AD
> itself, not to the filesystem. It's been a few years.
I'm not saying you didn't see it. Only that I never did. :-) They
*have* changed how ACLs are stored on files between 2000 and XP (IIRC).
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 25 Aug 2008 14:35:19 -0700, Darren New wrote:
> Jim Henderson wrote:
>> Well, arguably, there is - you put it in /tmp - most programs do that.
>> Then you just exclude the directory from your backups.
>
> Well, yes, but programs don't do that. KDE doesn't put the fingernails
> there. Firefox doesn't put the cache files there. Thunderbird doesn't
> put the index files there. VI doesn't put .swp files there. Etc.
True. But that's also what environment variables TMP and TEMP are for as
well. But you're right that FF doesn't put its cache files there;
there's a reason I flush my cache when existing FF (pain in the behind to
sync the directory with a zillion cache files).
> Basically, anyone who doesn't want to have to pick an arbitrary name and
> then somehow relate it back to the file it's related to isn't going to
> put it in /tmp/. And /tmp really isn't where you want to store all that
> stuff anyway, or you'll wind up filling up whatever partition /tmp is
> on, which is usually smaller than the partition your home directory is
> on.
There again, that's what the environment vars are for.
>> Demonstration I saw showed it pegging the CPU at 100% for nearly 40
>> minutes because the rights were stamped on each object. Come to think,
>> it wasn't the filesystem - it had to do with assigning rights in AD
>> itself, not to the filesystem. It's been a few years.
>
> I'm not saying you didn't see it. Only that I never did. :-) They
> *have* changed how ACLs are stored on files between 2000 and XP (IIRC).
I'm talking on server - ACLs in AD, not the filesystem. I could probably
reproduce it if it were worth my time. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> There again, that's what the environment vars are for.
I'm not sure what you mean. You'd change the environment variables for
each program? That doesn't sound like a good idea. And I expect there
are some programs that use $TMP that expect certain semantics to go with
it (like it gets cleaned up after a reboot) or some such, too.
> I'm talking on server - ACLs in AD, not the filesystem. I could probably
> reproduce it if it were worth my time. ;-)
Sure, I understand.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 25 Aug 2008 15:58:25 -0700, Darren New wrote:
> Jim Henderson wrote:
>> There again, that's what the environment vars are for.
>
> I'm not sure what you mean. You'd change the environment variables for
> each program? That doesn't sound like a good idea. And I expect there
> are some programs that use $TMP that expect certain semantics to go with
> it (like it gets cleaned up after a reboot) or some such, too.
No, that you'd have a path which was storage for temp files, system-
wide. In *nix, ISTR there's a call to "create a temporary file", no need
to track it by name because all the program needs is the file handle.
>> I'm talking on server - ACLs in AD, not the filesystem. I could
>> probably reproduce it if it were worth my time. ;-)
>
> Sure, I understand.
:-) It was a great deal of fun to watch.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> No, that you'd have a path which was storage for temp files, system-
> wide.
Um, right. Same with Windows.
> In *nix, ISTR there's a call to "create a temporary file", no need
> to track it by name because all the program needs is the file handle.
Um, no. If you want to close the file and reopen it later, because it's,
say, a cache file, then you need to know the name. How come people
invariably think a "temp file" means you never close it, reopen it, or
pass it to another program? In any case, I'm not talking about temp
files. I'm talking about cache files. And since programs *don't* do
this, a discussion of how it might be able to work without changing the
file system doesn't help anyway.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 25 Aug 2008 17:25:48 -0700, Darren New wrote:
> Jim Henderson wrote:
>> No, that you'd have a path which was storage for temp files, system-
>> wide.
>
> Um, right. Same with Windows.
Yes.
>> In *nix, ISTR there's a call to "create a temporary file", no need to
>> track it by name because all the program needs is the file handle.
>
> Um, no. If you want to close the file and reopen it later, because it's,
> say, a cache file, then you need to know the name. How come people
> invariably think a "temp file" means you never close it, reopen it, or
> pass it to another program? In any case, I'm not talking about temp
> files. I'm talking about cache files. And since programs *don't* do
> this, a discussion of how it might be able to work without changing the
> file system doesn't help anyway.
It's a question of programming practice. Kinda like passing laws that
duplicate other laws because the older laws aren't enforced.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
