[arch-general] pacman/libalpm/libfetch do not honor TMPDIR

[Leonid Isaev]

On Fri, 25 Nov 2011 18:57:22 +0100
Tom Gundersen <teg at jklm.no> wrote:

> On Fri, Nov 25, 2011 at 6:31 PM, Leonid Isaev <lisaev at umail.iu.edu> wrote:
> > On Fri, 25 Nov 2011 18:07:18 +0100
> > Geert Hendrickx <geert at hendrickx.be> wrote:
> >
> >> On Fri, Nov 25, 2011 at 10:55:55 -0600, Leonid Isaev wrote:
> >> > Actually, what is stupid is keeping /tmp in RAM. It is an important dir,
> >> > where you might have an valuable info in case of a system crash. I could
> >> > never understand the logic behind this choice.
> >>
> >>
> >> Reducing disk i/o.
> >>
> >>
> >>       Geert
> >>
> >>
> >
> > I find this a very weak excuse, because the normal desktop operation is not
> > I/O bound, and the dafaults must be safest. If you compile a lot/use a
> > lot of DB stuff, just mount /tmp to RAM in fstab but this is a special case.
> 
> Note that:
> 
> 1) FHS says: "Programs must not assume that any files or directories
> in /tmp are preserved between invocations of the program."

I didn't say anything about programs -- I meant the administrator. Suppose you
came across a pdf file which freezes your evince and the whole X. Then you'll
definitely would like to have a closer look at it and send it do evince devs,
but it's gone because of hard reboot.
> 
> 2) the contents of /tmp is deleted by initscripts on boot, so if you
> want to access stuff in /tmp after an unclean shutdown you somehow
> have to circumvent that.

Exactly -- use livecd, otherwise why not clean it rc.shutdown, on unmount?
> 
> Given the above, there is no reason not to use tmpfs on /tmp (and
> plenty of reasons to do so). If extra space is required on /tmp, then
> the most efficient solution is to add to the available swap space.
> 
> If you have important data, don't put it in /tmp or /var/tmp as
> neither has any guarantees about persistence.
> 
> -t

-- 
Leonid Isaev
GnuPG key ID: 164B5A6D
Key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20111125/32f9be1a/attachment-0001.asc>