1 |
On Saturday 19 January 2008, Olivier Galibert wrote: |
2 |
> On Sat, Jan 19, 2008 at 10:18:35PM +0000, Duncan wrote: |
3 |
> > Richard Freeman <rich0@g.o> posted 4791F359.1050500@g.o, |
4 |
> > > I think that this would probably warrant an elog. Sure, anybody who |
5 |
> > > knows the "correct" way to admin unix doesn't put anything important in |
6 |
> > > /tmp - but educating our users before blowing away their data isn't a |
7 |
> > > bad thing. We shouldn't assume our users are idiots, but this is an |
8 |
> > > obscure enough piece of admin knowledge that I think that users will be |
9 |
> > > impacted by the change. |
10 |
> > |
11 |
> > Obscure? It's the directory name (says another with both /tmp and /var/ |
12 |
> > tmp on tmpfs). How much less obscure can you get than announcing it |
13 |
> > every time the path is referenced or specified? Who could reasonably |
14 |
> > argue that tmp doesn't mean tmp? |
15 |
> |
16 |
> Tmp has never meant "erase at restart", because restarts are often not |
17 |
> predictable. Tmp has sometimes meant things like "erased after a |
18 |
> week", or "erased when space gets low", but never "erased after |
19 |
> restart" which is just unusable. |
20 |
|
21 |
dont know where you get this "unusable" business from. ive never had a |
22 |
problem with it and ive been using WIPE_TMP since i introduced it which has |
23 |
been over a year (maybe two or three). nor has it been a problem for |
24 |
everyone who mounts /tmp as a tmpfs. nor anyone else who uses /tmp |
25 |
correctly. |
26 |
|
27 |
> Frankly, if I'm writing a long email (which mutt stores in /tmp) and a |
28 |
> powerloss makes it gone even if I was saving it from time to time |
29 |
> while I was writing it, I'll get annoyed. Severely annoyed. |
30 |
|
31 |
i dont know what sort of magic you think is going on behind the scenes. there |
32 |
is no guarantee that mutt will write every byte after you type it, flush the |
33 |
I/O buffer, and make sure it gets synced to the disc. or that the kernel has |
34 |
actually synced it to the disk. or that the disk has actually written it out |
35 |
of its own I/O buffer to the drive. |
36 |
-mike |