Ian Jackson wrote:
> Timo Juhani Lindfors writes ("Re: /tmp as tmpfs and consequence for imaging software"):
> > That does not seem to be so easy:
> > http://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28251
> bug in libc which libc maintainers don't want to fix even though
> there's a tested patch
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=28250
> effects on perl, which maintainers think is bug in libc
>
> Result: DATA LOSS BUG, still present THIRTEEN YEARS LATER:
>
> mariner:~/junk> echo hi >t
> mariner:~/junk> perl -pe '1;' <t >/dev/full
> mariner:~/junk> echo $?
> 0
Which is a pity. Has it ever been sent to glibc upstream?
With that said, it's not actually hard to test programs' behavior on a
full disk and make them behave well in common cases. For example,
ikiwiki never lets a full disk cause it to write truncated files, and if
a user is editing a page and tries to save with a full disk, it will show
an error and keep their changes buffered for them to resubmit.
And other languages seem to get it right (this is trying the magic buffer
size 131072 from the paper):
joey@gnu:~>runghc foo.hs >/dev/full
<stdout>: hFlush: resource exhausted (No space left on device)
zsh: exit 1
--
see shy jo
Attachment:
signature.asc
Description: Digital signature