> >>>> Dot Locking: yes > >>>> File Locking: fcntl > Gtk-doc: no
This i think is the default. With the ports system, the *bsd guys are free to configure it how it suits the system, but its correct I guess. There are problems with lockf/flock on some implementations I think, I can't remember the details, probably to do with NFS, etc. > So this looks very promissing. Procmail acquires both a "kernel-lock" and > a "dotfile" lock (the filename is configurable): > > procmail: Locking ".inbox.lock" > procmail: Assigning "LASTFOLDER=inbox" > procmail: Opening "inbox" > procmail: Acquiring kernel-lock > procmail: Unlocking ".inbox.lock" > > I guess it is safe to assume that in my environment I will not have > problems with concurrent access to my mbox files by Evolution and > procmail, since they share and honour the same locking mechanisms. Note that we use "mailbox.lock", no prefix is added (e.g. "."). Hmm, we also reverse the lock process, we perform a filesystem lock before the .lock lock, although that shouldn't be too big an issue. But I guess it should work anyway, since we overlap on one of the lock mechanisms. > Thanks again for the reply, and apologies for the long posting. I did > quite a bit of searching on-line before asking the list, and the details > may be useful to the next person attempting the same set-up. Note that the 1.1 series code has support for whole directory trees (you just point it to ~/incoming-mail and it picks up all the mbox files present and it lists the tree inside evolution, like imap does. 1.0.x will do this for maildir trees too, but not for spool trees (which conveniently, do not require locking at all, but have other tradeoffs). _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
