You're running imapd on NT (using something like inetlisn), right? Is there a reason why you aren't running imapd on UNIX?
Is there a reason why you choose to use the traditional UNIX mailbox format on NT instead of mbx? mbx is the default in the NT build. > 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. Why would you be running an IMAP server on a non-NT version of Windows? Win95/98/Me are dead, and the corpse has started to stink. Although I can understand diehards continuing to run it on the desktop, I can't imagine why people would use it as a server (particularly an IMAP server!) > 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. Yes, there is no "kiss of death" feature in the traditional UNIX mailbox driver for Windows (both NT and non-NT). The assumption is that anyone using traditional UNIX format on the PC is doing so as a desktop and not as a server > 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. On UNIX, the older session having a traditional UNIX format file is killed. > As for support, it is ironic that when the 'unsupported' software > is *used* correctly, the so-called 'supported' software is where the > problem lies. I don't understand what you mean by this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
