On 11 June 2012 22:59, Bjørn Mork <bj...@mork.no> wrote: > Aneurin Price <aneurin.pr...@gmail.com> writes: > >> (Note that we are talking about applications which fail gracefully >> when confronted with ENOSPC, > > Are we? What's the problem then? >
Honestly, I have no idea. It's clear that some people think storing 'large' temporary files in /tmp is 'broken', for unspecified values of 'large', but I don't understand why and nobody seems interesting in explaining the reasoning when they can just declare it axiomatic. My best reasoning is that the application shouldn't fail at all in this case, but should find some way of working despite running out of storage space. Obviously that would be great, but I can't really imagine all that many cases where it's likely to be possible (or really *any* cases where it's likely to be worth going to the extra trouble). It does annoy me quite a lot that people are calling applications broken without even *attempting* to define what they might deign to call *not* broken. >> but which are likely to do so more often when the size of /tmp is >> restricted.) > > Yes, but the tmpfs correlation is weak. There is absolutely no > guarantee that there will be more space available on the root file > system than a default tmpfs. In anything resembling a 'normal' system (ie. the kind where one might be using the defaults) I would say that the tmpfs correlation is so strong as to be very nearly 1:1, and this seems like the crux of the matter; that is after all the reason that these applications are failing when /tmp is switched to tmpfs. It is almost a complete certainty that on any given system there will be more space available on the root filesystem than a default tmpfs, unless that system has requirements so specific that the choice of defaults is moot. Sure there's no *guarantee*, but it is exceptionally likely; if you do seriously believe otherwise (ie. you're not just pointing out that it *might* not be the case), I'd say that's sufficiently extraordinary a claim as to require extraordinary evidence. -- 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/cahb+spbfe0zcryetorxbnu0mfdfoncmme_qcykhznyjj73v...@mail.gmail.com