Hi Mutters, I haven't been following the thread but just to reply to a few points with the names of the posters removed in order to focus on content rather than who said what:
> > It's not your > > mail client's job to protect you from every conceibable system > > failure which might cause data loss, nor should it be. If the issue is whether saving a copy or sending a copy happens first, it seems obvious to me in most cases it doesn't matter. But, as long as it is not any more difficult to do it correctly, maybe we can use a journaling file system as a very rough analog. We expect that any update gets committed to the journal before it gets committed to the real file. If the lights go out, we replay the journal and the file (depending on some minor details like what was journaled blah blah blah) gets restored to a coherent state. So it seems pretty clear that, if there are no overriding considerations the first thing that ought to happen is that a local copy of the email is saved to disk before the email is sent. Then the email is sent, the the saved copy is marked sent. So in those rare cases, there is a consistency mechanism that leaves things in a known state. > > And for every other > > case, the current behavior is the far superior one because it can > > not mislead you into thinking you sent a message you did not, The flagging operation of a saved message is much faster than saving the whole message. So while it's true having a saved copy with no status information attached to it could lead to this case you mention- which is certainly bad, it seems to me that designing things so that the saved email is created with an unsent flag and after the email is sent the flag on the sent copy is set to sent is easy and make sense. > It is quite easy to have a setup, where I can verify if the mail was > sent if there is any doubt. Yes, and the above paragraph would seem to be one way. > I'm relying on my mail client, that it safely stores a message of > every message sent. This seems reasonable to me. I understand that means nothing here on the list and probably not much elsewhere ;) but at the same time, free speech is good and no electrons were harmed in creating this email. > > I hesitate to go far as to say that if you think saving the message > > first is the right behavior, you are simply wrong... but I'm > > definitely thinking it. =8^) I go with the opposite opinion. I think there is an obvious precedent here in journaling filesystems, which are vitally concerned with data and/or metadata consistency. It does not necessarily mean that an email client has to be coded the same way or that the same level of rigor is appropriate, but in the absence of compelling reasons to the contrary the question arises, why not then? > You might consider it wrong but I do not seem to be the only one > thinking the old order is the correct one. Old stuff is usually better in my opinion. The problem is that most people seem to think you have to keep throwing features out there when what they had was perfectly fine at some point. And most Linux distros make it very hard never to update some app or middleware. When I ran Slackware I got around this by building everything from source and then never updating apps I was happy with. But there is a lot of home sysadm work involved with that and of course some risk of losing out on security updates for various and never-ending screwups. In the end, package-managed distros make it very easy to get the latest, but not necessarily the best. /jl
