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