Joey Hess dixit: >If programs that write large files to /tmp are changed to usr /var/tmp, >then over time a system will accumulate orphaned large tmp files in >/var/tmp. Nothing will come along and clean them up.
This is indeed a valid point. But that’s no regression; /tmp has always been for small short-lived files, and /var/tmp for those that are not one of them or not both. The question whether there needs to be a way to store large temporary files that are cleaned up automatically (yes, please), when (Ben Hutchings fsck experience comes to mind) and how (?) should be orthogonal to the /tmp as tmpfs discussion (but be done). For what it’s worth, I’ve run into limits when having /tmp as a filesystem more often than when it was in RAM. bye, //mirabilos -- <ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^ <mika> sorry, no idea and rebasing just fscked │<mika> Segmentation <ch> should have cloned into a clean repo │ fault (core dumped) <ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
