> > You're running imapd on NT (using something like inetlisn), right?
Yes, we are running imapd on NT, and other versions of Windows and have done so from W95 forward. We are using a highly modified version of inetlisn as a front-end. > > Is there a reason why you aren't running imapd on UNIX? Yes, not everyone has 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. The reason we chose UNIX format is purely due to format simplicity (for SMTP mail delivery). I understand that mbx has better share characteristics and we will likely move to it (or write a DB driver). > > > 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!) I did not say I recommended this, but imapd does run there (with caveats). > > > 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. Thanks for the clarifications. > > > 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. I had interpreted your statement that imapd was 'unsupported' as a server on Windows to mean 'it does not work'. And by 'used correctly', I meant used with NT (not Win9x). Given that, and the fact that a somewhat obscure problem like this is not a problem with imapd, but a problem in an extremely popular email client just makes me wonder about why imapd should not be running as a server on NT; it seems to work well enough. -- Carl Stehle
