Temporary files

goodoldmarty at gmail.com goodoldmarty at gmail.com
Wed Sep 26 05:03:00 PDT 2007


> Either way, I'd like to hear feedback about this issue. I feel it's an audit 
> issue... a bug.
Actually it's just a universal lack of regard.
*** No program should maintain any large amount of unencrypted data in a
temporary disk file for any indeterminate time. ***
I think GNU needs to hear that message, and move in that direction.

I agree that tmp files are a nuisance, and should be more manageable.
I would also like to see some better thought for log files and .conf
files. Spool files might also be an issue. And I must also mention that
SWAP space might need attention.

I learned that programs using priv-sep can't always recreate their
private dirs in /tmp. The /tmp/private dirs need to be created by root.
This gets old really fast when the entire /tmp dir gets wiped.

Vim makes it's stupid.swp files in the PWD or where the original lives,
and Gedit leaves mouse droppings~ everywhere.

It's a mess, but temporary files and the like are very problematic, and
guidelines need to come from way upstream or you risk creating untold
conflicts. Probably safer to write a script to locate all those goofy
outdated files and delete them periodically.

> The variable here is the goals for HLFS-1.0. Either keep plowing ahead, or 
> settle down and use what we have.
> 
Whoa, if it is build-able and working it's probably not broken, so don't
change anything and freeze that release as -stable.
My HLFS has been online 24/7 >30 days without any problems, and I added
a lot of things that tax it. ( Mine is as stable as any Fedora
release;-)   You can always bravely run the LTP suite on it ...

> but it can't be automated for ALFS.
> 
Next they will want binary installers and bypass reading the book
altogether. Simple; if you can't build it you shouldn't have it.


Marty B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3651 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070926/9ffe3f99/attachment.bin>


More information about the hlfs-dev mailing list