[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