On Sat, 4 Aug 2007, Wietse Venema wrote:
> Christopher E. Brown:
> > On Mon, 23 Jul 2007, Wietse Venema wrote:
> >
> > > Christopher E. Brown:
> > > > True MailDir, and the extented Maildir+ are NFS clean.
> > >
> > > What happens with non-idempotent requests, such as:
> > > - client requests link(tmp, new)
> > > - server reply is lost
> > > - server crashes and loses the request ID cache.
> > > - client times out
> > > - client requests link(tmp, new) (retransmission)
> > > - server replies with error (file exists)
> >
> >
> > Maybe I am missing somthing here, please fill me in if I am. I can think
> > of corner cases where this could cause duplicate messages.
> >
> > It is not ideal, but better than losing the message. Also, while this
> > would seem to me more likely to happen over NFS (timing less critical,
> > larger window), I would think that a system crash at the wrong moment
> > could trigger the same issue on most any filesystem.
>
> This is not a problem with LOCAL file systems (if the machine
> crashes, then Postfix dies with it; transaction is not completed,
> and the client remote SMTP client retransmits the messae some time
> later).
>
> Wietse
Ok, now I am confused. I though we were talking about maildir delivery or
IMAP triggered folder to folder copy/move.
I never run my postfix spool on NFS, only local disk.
For maildir delivery I would assume that the accept fed to the remote on
commit to the local queue had already happened, and that the deliver (via
local or maildrop) would fail on the dup filename, and tempfail the
delivery. When the retry happens the timestamp based portion of the
created file would be different and the local mailbox delivery would go
through.
For the copy/move we would see a "failed" copy that actually worked, or a
move that failed leaving both the original and the new copy in place.
|
