On Saturday 19 January 2008, Olivier Galibert wrote:
> On Sat, Jan 19, 2008 at 10:18:35PM +0000, Duncan wrote:
> > Richard Freeman <rich0@g.o> posted 4791F359.1050500@g.o,
> > > I think that this would probably warrant an elog.  Sure, anybody who
> > > knows the "correct" way to admin unix doesn't put anything important in
> > > /tmp - but educating our users before blowing away their data isn't a
> > > bad thing.  We shouldn't assume our users are idiots, but this is an
> > > obscure enough piece of admin knowledge that I think that users will be
> > > impacted by the change.
> >
> > Obscure?  It's the directory name (says another with both /tmp and /var/
> > tmp on tmpfs).  How much less obscure can you get than announcing it
> > every time the path is referenced or specified?  Who could reasonably
> > argue that tmp doesn't mean tmp?
>
> Tmp has never meant "erase at restart", because restarts are often not
> predictable.  Tmp has sometimes meant things like "erased after a
> week", or "erased when space gets low", but never "erased after
> restart" which is just unusable.

dont know where you get this "unusable" business from.  ive never had a 
problem with it and ive been using WIPE_TMP since i introduced it which has 
been over a year (maybe two or three).  nor has it been a problem for 
everyone who mounts /tmp as a tmpfs.  nor anyone else who uses /tmp 
correctly.

> Frankly, if I'm writing a long email (which mutt stores in /tmp) and a
> powerloss makes it gone even if I was saving it from time to time
> while I was writing it, I'll get annoyed.  Severely annoyed.

i dont know what sort of magic you think is going on behind the scenes.  there 
is no guarantee that mutt will write every byte after you type it, flush the 
I/O buffer, and make sure it gets synced to the disc.  or that the kernel has 
actually synced it to the disk.  or that the disk has actually written it out 
of its own I/O buffer to the drive.
-mike