Re: [Mutt] #3236: mutt: should use /var/tmp for mail drafts by
On 2009-06-04 12:29:57 -0500, Derek Martin wrote:
> On Wed, Jun 03, 2009 at 08:50:50AM -0000, Mutt wrote:
> > Comment(by vinc17):
> >
> > I agree with madduck.
> > [http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES FHS] even
> > recommends: ''Although data stored in /tmp may be deleted in a site-
> > specific manner, it is recommended that files and directories located in
> > /tmp be deleted whenever the system is booted.''
>
> That sounds an awful lot like a recommendation to me, not a
> requirement. So, a distribution which chooses not to behave this way
> is still compliant. I believe there still are Linux distributions
> in somewhat widespread use today which do not behave this way, though
> I'm not at liberty at the moment to make a survey to determine that
> with any certainty. So yes, as you have just pointed out, the
> cleaning policy of /tmp IS a distribution-dependent behavior. Thank
> you.
Yes, but since it is a recommendation, it is likely that many systems
will follow it, and at least you can't blame systems for following a
recommendation. Choosing /var/tmp instead of /tmp will improve the
behavior on systems that follow the recommendation, and should be
equivalent on the other systems. If /var/tmp doesn't exist (which
would be against FHS), then /tmp could be used as a fallback.
> > A system reboot can occur almost at any time, for various
> > reasons. And it generally occurs much more often than disk
> > failures.
>
> So? Unless I'm mistaken, a message that's in $tmpdir is one that the
> user is *actively* editing
No, not necessarily...
> (or at least one which Mutt thinks is being edited), or else it
> would be moved to postponed.
The user can start editing the message, save the message (from the
editor), do something else for 10 minutes then go back to the message.
Postponing the message is an unnecessary operation.
> If the system goes down *FOR ANY REASON* while the user is in the
> middle of editing the message, data loss is at least somewhat
> likely, regardless of where you put it.
In general, if the file is stored in a directory that isn't erased,
only a part of the message is lost (e.g. the last characters entered).
But this depends on whether the user saves the message regularly or
the editor does it for him (under a different filename).
Between losing the whole message and losing just a part, I prefer
the latter!
> > So, the fact that disk failures can occur is not a reason not to
> > change /tmp to /var/tmp (or the user's home directory).
>
> You're right, it's not a reason not to change it. However it is a
> reason that changing it may be largely pointless. The other reasons I
> gave (e.g. potentially breaking Mutt on non-Linux systems) are
> reasons not to change it.
I don't see why it would break Mutt.
> > Mutt ''already'' uses the home directory by default for postponed
> > messages.
>
> Just because a behavior exists does not make it the right behavior.
So, propose a change (for the default behavior).
> Postponed messages are not at all the same thing, because:
>
> - they exist in a mail folder which is essentially unique to Mutt
> - Mutt is NEVER actively editing them while they are there
> - As a mail folder, postponed can be a maildir, if the user cares
> - As a result, file locking is not an issue
Temporary files for mail editing could be implemented in the same way
as mail files of a maildir folder.
> Temp files, by contrast, are (AFAIK) currently always single files,
Note that mail files of a maildir folder are also single files.
> always at least potentially in an active state of being modified (as
> far as Mutt is concerned), and as such are always subject to locking
> issues.
Locking is not necessary. You just need unicity.
> This is only likely to be an issue if a user tries to edit
> the file in more than one editor session, or do funky things to
> modify the temp files directly via external programs, but I've known
> people to do such things (even if you do not)...
This is not the normal use when editing a mail (I'm not talking
of attachments). People who do this kind of things when editing
a mail should be aware of possible problems and configure Mutt
accordingly.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)