This is an interesting behavior, to put it mildly. How am I supposed

to notify my users to please log off now? How about in the middle of the

night, when the server does a reboot? Many connections will be still

active, but no user will be active to close them.

Will this be fixed in the next release?

Not sure what to tell you.  These functions are only completed when the client completes the transaction by closing the connection.  If the connection is broken then the EXPUNGING mail that the person using the connection expects to be able to recover might be worse than than leaving the mail undeleted.  This is especially true when the loss of mail is usually considered a greater problem than not deleting mail.  In addition, many mail clients, including t-bird can send a manual expunge under user control after they do a delete to confirm the deletion without closing the connection.

How do I gracefully shut down Mercury (Mercury32 in NDS mode)? I noticed, that if an imap connection is running, closing Mercury will loose several committed changes, i.e. deleted mail will re-appear etc.

Is there a way to tell Mercury to finish current transactions and then close?

Greetings

Markus

> How do I gracefully shut down Mercury (Mercury32 in NDS mode)? I noticed, that if an imap connection is running, closing Mercury will
> loose several committed changes, i.e. deleted mail will re-appear etc.
>
> Is there a way to tell Mercury to finish current transactions and then close?

This is a problem with the client not sending an EXPUNGE command to immediately delete the mail.  The EXPUNGE command in this case is only done when the account is closed.  This is complicated by the fact that MercuryI does not support EXPUNGE when there are multiple connections to an account and clients like Thunderbird by default maintain multiple connections to an IMAP4 account.

The only way to do this is to have all the users close out their IMAP4 accounts before you close Mercury.

Um, we might be talking about different things here. I'm not talking about EXPUNGE, but I'm talking about a mail being marked "deleted". This is how it should work:

1. Client send "delete this message".

2. Server marks message as deleted.

3. Server is shut down, while client is still online

4. Next client connect: Message is still marked as deleted.

This is how Mercury does it:

1. Client send "delete this message".

2. Server marks message as deleted.

3. Server is shut down, while client is still online

4. Next client connect: Message is no longer marked as deleted.

There are a whole lot of things that Mercury seems to not commit to disk as long as the client connection is still open. This makes a server crash a very delicate experience. But I recently discovered, that even closing Mercury via File/Exit will cause it to "forget" a lot of status information.

Greetings

Markus

Um, we might be talking about different things here. I'm not talking

about EXPUNGE, but I'm talking about a mail being marked "deleted". This

is how it should work:

1. Client send "delete this message".

2. Server marks message as deleted.

3. Server is shut down, while client is still online

4. Next client connect: Message is still marked as deleted.

The process is

1. The mail client deletes the mail locally and may or may not send the EXPUNGE command to the server to actually delete the message until closing the account.  May clients do have the capability to manually send the EXPUNGE command through user action, i.e. both Outlook and OE have the "Purge deleted messages" to force the EXPUNGE.

2. The EXPUNGE command is received by the server and may or may not be executed because there are multiple IMAP4 connections.  The EXPUNGE with multiple connections to an account is an optional IMAP4 function and is not supported by Mercury/32 among others.  In this case the EXPUNGE is only executed when the last connection to the account is closed.

3,  No mail in an IMAP4 account is ever deleted until the EXPUNGE command is successfully completed.  If the connection to the account is lost prior to the account being closed then the message will not be deleted.

You can verify this for yourself by turning on session logging in MercuryI and then deleting a message to see what happens.

Hi Thomas,

thanks for the clarification, but I am _not_ talking about EXPUNGE. I'm talking about the "deleted" flag: Before an email can be removed for good by expunge, it needs to be flagged for deletion.

Mercury is keeping certain changes in RAM, until the last connection to the mailbox is closed, _then_ the information is written to disk (in this case, to the .PNM file).

I always thought that closing Mercury causes it to flush out this stuff to disk. Unfortunately our tests indicate that this is not the case. That means, if any connection is still open, and you close Mercury, you run the risk of loosing updates. Hence my question, how to close Mercury and cause it to flush out pending data to disk first.

Greetings

Markus Borst

Hence my question, how to close Mercury and cause it to flush out pending data to disk first.

There is no way to do this with open connections in place.  The clients must be disconnected to close out the connections prior to shutting down MercuryI.

[quote user="Thomas R. Stephenson"]

Hence my question, how to close Mercury and cause it to flush out pending data to disk first.

There is no way to do this with open connections in place.  The clients must be disconnected to close out the connections prior to shutting down MercuryI.

[/quote]

This is an interesting behavior, to put it mildly. How am I supposed to notify my users to please log off now? How about in the middle of the night, when the server does a reboot? Many connections will be still active, but no user will be active to close them.

Will this be fixed in the next release?

Greetings

Markus