On Mon, 2002-10-21 at 17:19, Thomas Wouters wrote:
Requiring msync() is fine, that's done after each change, but there should be better solution than re-mmap()ing to notice the changes. I think FreeBSD checked the changes after fcntl() locking changes :)
Hmm. More bad news; flock() doesn't work over NFS. That is, local processes see and honor the lock even on NFS filesystems, but other machines don't see the lock at all. fcntl() doesn't work at all (but that's probably because we're not running lockd.)
flock() doesn't matter, it's used only for mbox locking where .lock file would work instead just as well.
That aside, this issue isn't that big an issue for us. The same-client-connecting-twice case we can solve by configuring the layer-4 ethernet switch to connect the same ipaddress to the same real server, so that mmaps() are properly shared and all. We might want per-mailbox locks so that only one real server can open a specific mailbox (but do so multiple times) but I'll figure that one out later.
OK. I think this could be fixed internally too. Or this is mostly a problem with index files, mbox/maildir files are currently re-mmap()ed every time they're accessed (but I'll change mbox not to do that later).
Indexes currently have "sync_id" in their header, it's changed whenever the file size is changed so other processes then know to re-mmap() it. This could be optionally changed to be updated every time the file itself has changed to force others to mmap() again. The sync_id change itself could be checked using lseek() + read().
If fstat() or stat() doesn't show mtime changes, that could be a bit worse problem. I think I'm relying on that with some things.. At least new mail is checked by seeing if Maildir/cur's mtime matches .imap.index's mtime.