Created attachment 1742305 [details] Patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked Description of problem: Using the roundcube webmailer (package roundcubemail.noarch) leads to error messages when deleting or moving messages from / between mailboxes. Version-Release number of selected component (if applicable): uw-imap-2007f-25.fc33 How reproducible: Install iw-imap and roundcubemail, configure roundcube to use the local imapd as backand. Use the web frontend, select a mail message and immediately delete or move to a different folder Steps to Reproduce: 1. log on to the roundcube web UI 2. select a mail message 3. immediately press the Delete button Actual results: A red area appears in the web UI with the text "Failed to move message to Trash !" and the message remains in the current folder Expected results: The message disappears from the current folder and is moved to Trash Additional info: Waiting a few seconds between selecting a message and pressing the delete button (or moving the message to a different folder) avoids the problem, but this is really annoying and confusing for ingenuous users. In the maillog the following message appears: "Killed (lost mailbox lock)". Actually this is an intended behaviour of imapd, as the authors explain in the FAQ #7.19 . I added the following section there regarding my modification, available only for the unix/Linux variant as i have no possibility to test on other platforms: However, the unix version is a bit more tolerant. When the server detects, that a lock is set on the mailbox, it retries to obtain it until 15 seconds after the creation time of the lock, if the lock is not already that old. Only after this phase of retrying it sends the "kiss of death" to the competing process. This way the scenarios outlined above and the related errors probably displayed to the users are mostly avoided. A short concurrent access e.g. to check for new mail should not cause some kind of outage and confuse the users. On the other side, a short waiting time for the lock to be released should be acceptable. A particular experience was using the web mailer "roundcube" (please see http://roundcube.net/ ). It is closing imap connections by only fractions of a second after opening another one yet causing this imap server to detect an existing lock and requesting the termination of another server instance, what makes roundcube assume something went wrong. Probably this shortly later closing of connections is actually a matter of deferred execution in the browser, who is the actual client of roundcube in turn, so this phenomenon is probably (unclear) not even a fault of the roundcube implementation.
Created attachment 1742307 [details] spec file to build the uw-imap with the attached patch file
Created attachment 1742726 [details] Better (in case of clock skew) patch to imapd-2007f to enhance robustness for the situation, the mailbox is locked This way the retrying to obtain a lock on the mailbox is not sensitive to the case, that the clock jumps during waiting for the lock to be released (counting down instead of watching time(0) )
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I noticed, that uw-imapd has disappeared from Fedora. What a pity. Together with the decision of the thunderbird maintainers to drop support for movemail, this would force me to some remote mailbox access service or to use cyrus imapd with e.g. it's non-trivial mailbox backup options. In any case with the superfluous need to authenticate to access a local file. Still i haven't seen another mailbox format or solution for local mailbox file access that i found really convincing. However, thanks to the fact, that the sources iv uw-imapd cannot be destroyed, i still use it. I wait for the day, that incompatilbilities introduced in glibc and friends will kill the chance to even build it.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.