We were not very clear in describing the IMAP transactions that led up to the problem with message flags we reported. From your comments, related problems that have been reported before, and further testing we found as follows:
1. The situation on non-NT versions of Windows, where flock() is a no-op, should be expected. In this case, the INBOX (Unix format) sharing (locking) protections of imapd do not apply and the email client is given read-write access on both connections. Since INBOX is non-sharable, data integrity is not guaranteed for writes. 2. On NT versions of Windows (where flock() is implemented), the end results are similar but for a different reason. While Connection 1 is open and in IDLE state, Connection 2 is used to 'SELECT INBOX'. The response includes 'PERMANENTFLAGS ()' and several indications of READ-ONLY state, but the client ignores these and sets the flags anyway. Of course, the flags are reset after Connection 2 terminates, (since PERMANENTFLAGS was null) as per IMAP specification. Presumably this does not happen on UNIX as most people (wisely) choose to use mbx format and locking is always implemented, making the INBOX file fully sharable. Hence a READ-ONLY INBOX never exists. In fact, we verified that message flags are treated correctly when moving messages between mbx folders. As for support, it is ironic that when the 'unsupported' software is *used* correctly, the so-called 'supported' software is where the problem lies. -- Carl Stehle
