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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1205271759070.24...@herc.mirbsd.org
