[Dovecot] Files Moving From /New to /Cur
Using Dovecot 1.2-9 with Maildir and layout=FS.
We have our own delivery pushing messages to the /new and then /cur folder eventually. When I have an IMAP client attached, there is apparently some sort of race going on. I believe that Dovecot is moving files from /new to /cur (and renaming them) before our own delivery gets the job done.
This is causing a problem for us. Is there a way to disable this in Dovecot? I have the LDA section commented out of the config file..so I don't think that's in play. Bottom line is that I don't want Dovecot to move any files around whether an IMAP client is attached or not (except for handling the IMAP COPY/APPEND).
Regards,
Tony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 18 Jan 2010, Tony Rutherford wrote:
We have our own delivery pushing messages to the /new and then /cur folder eventually. When I have an IMAP client attached, there is apparently some sort of race going on. I believe that Dovecot is moving files from /new to /cur (and renaming them) before our own delivery gets the job done.
This is causing a problem for us. Is there a way to disable this in Dovecot? I have the LDA section commented out of the config file..so I
No :-) this is part of Maildir Well, yes: patch Dovecot's sources.
don't think that's in play. Bottom line is that I don't want Dovecot to move any files around whether an IMAP client is attached or not (except for handling the IMAP COPY/APPEND).
What are you mean with "move"? The move from "new" to "cur", when the message has been seen? Or the "rename" of the filename for status / keyword change?
===
Maildir defines the delivery process as:
- create the file in "tmp/"
- dump all data into it, hence, close it
- rename() the file into "new" or "cur".
- be done with the file (aka don't try to re-open)
There is no race-condition that way.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBS1Vq87+Vh58GPL/cAQLcaggAmD7/BRxcT6laO+K+cnSKpC+ILNxLCZpE oSL8gmjOCGdHVdx4NfXwcaIlFUomPm2+KIdnLHFLafH2xxZuO5qICVOYDHIyDPZO EEevz+M6NIHRh2eO9cY6T4JZfiWbWzEvbg+F7+OM6zJ42w1OQIHI/+JFdq45YM7c rb//mFqBCJlSj6/dXYfb8xFUrH+OrNKoxHCybyYJjR906AOM3DR9SN/oMThXflpv fBdg0uoQTT5uL8IPx++2ZwuDhuI1ixO1R2qGPIua5U/lx5/2X/puUFcQpHyt2/WC JAt2KdTjJMs2027O8tOK0vznnW1flu4A5jv6pIJrUIf7eSv6LhqxzQ== =cNm+ -----END PGP SIGNATURE-----
Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 18 Jan 2010, Tony Rutherford wrote:
We have our own delivery pushing messages to the /new and then /cur folder eventually. When I have an IMAP client attached, there is apparently some sort of race going on. I believe that Dovecot is moving files from /new to /cur (and renaming them) before our own delivery gets the job done.
This is causing a problem for us. Is there a way to disable this in Dovecot? I have the LDA section commented out of the config file..so I
No :-) this is part of Maildir Well, yes: patch Dovecot's sources.
don't think that's in play. Bottom line is that I don't want Dovecot to move any files around whether an IMAP client is attached or not (except for handling the IMAP COPY/APPEND).
What are you mean with "move"? The move from "new" to "cur", when the message has been seen? Or the "rename" of the filename for status / keyword change?
===
Maildir defines the delivery process as:
- create the file in "tmp/"
- dump all data into it, hence, close it
- rename() the file into "new" or "cur".
- be done with the file (aka don't try to re-open)
There is no race-condition that way.
Bye,
- -- Steffen Kaiser
I'd like to apologize a bit for this thread. It stems from me being a relative newbie to email protocols/specs and who is responsible for what. I think I have it a bit straighter in my mind now. The real issue with our scenario is that the delivery software we have in place is breaking spec, and attempting to deliver to /new and then (after performing a few actions), rename to /cur. Long story, but the problem is made far worse by the "few actions" that the lda performs...resulting in an inconsistent state if the attempted rename to /cur fails because the file has already made it to /cur via th MUA. Anyhow, I have made changes on the delivery side as this is where the root of the problem lies. Thanks for the help.
Tony
participants (2)
-
Steffen Kaiser
-
Tony Rutherford