Wookey dixit: >But there is this issue of the way its vfs does temporay unpacking in >/tmp. That makes sense in the 'this is temporary, it should go away on >reboot' sense, but some big files will use up a lot of ram when /tmp >is tmpfs. > >I don't know what the right thing to do about this is, but the 'set >TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what >things will be unpacked under the VFS over the next days/weeks. I
Yes. What I was trying to say was: set TMPDIR for many operations, but file managers, such as mc, should be patched to apply heuristics to determine whether to use /tmp or /var/tmp. >don't want _everything_ to go in /var/tmp and not get cleaned up >automatically (is there cron job that does this for old files?) I think there is, but may be confusing with BSD, from which I know for sure /tmp is cleaned at reboot and, daily, files older than seven days. (Note that we see another benefit of tmpfs for /tmp and for *most* files here: when mc segfaults again, its tempfiles will not linger around long when in /tmp on tmpfs…) >Perhaps mc should get clever and change TMPDIR itself on the fly for >large files, but I don't know how practical that is. Yes! >here's a case where a lot of space gets used in there: open a .ppt >(powerpoint) file in libreoffice. The conversion involves writing a >file in /tmp/<mktmpdir> for every page/image. To open an image-heavy >256Mb .ppt I have lying about here, generates 382MB of files in /tmp. Ouch. (But nobody said Staroffice/Openoffice/Libreoffice/whatsitsname was light.) This sounds like another of these cases where the software would benefit from changes _independent_ of the tmpfs setting. (It could for example do that only for the first few pages, doing others as the timeline progresses.) >So I'm with serge that this can be a real-world problem. I'm I don’t disagree but still stand by that these are corner cases. bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- 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.1205271749020.24...@herc.mirbsd.org
