[arch-general] pacman/libalpm/libfetch do not honor TMPDIR
C Anthony Risinger
anthony at xtfx.me
Fri Nov 25 17:23:56 EST 2011
On Fri, Nov 25, 2011 at 4:32 AM, Mauro Santos
<registo.mailling at gmail.com> wrote:
> On 25-11-2011 07:46, C Anthony Risinger wrote:
>>
>> ... however, i would consider it a bug for applications to
>> store *very* large files (exceeding 50-100M or so) in /tmp -- /var/tmp
>> would be more appropriate, even for ephemeral/transient files -- idk
>
> Just out of curiosity, why do you say that? Is it a good practice rule
> or something like that?
i'm not sure about the best-practice aspect, but it's what i do at
least ... reasoning being /var/tmp is more likely to be backed by
permanent storage (read: larger), and since it's more "persistent-ish"
than /tmp, there's a better chance it'll still be there if my program
were to terminate early/crash/etc. i suppose if i have to work with
that much data, i'd rather not have to
re-extract/re-compute/re-<whatever> if the app chokes early.
i don't know if thats a sound reason (FHS doesn't specify relative
sizing, or set any size expectations at all), but this tend to hold in
practice. in my mind, /tmp is for rapid processing of data in chunks
(eg, like a buffer), and should be cleared often by your app as it
works -- /var/tmp can hold the entire dataset if need be.
... data must still be throwaway in the end. ultimately, if you
*really* want data to stick around, and it *really* is important ...
then don't let the only copy of it lie around in a directory called
"tmp" :-) ... use your app's /var/lib instead.
--
C Anthony
More information about the arch-general
mailing list