On Thu, Jan 09, 2003 at 05:04:04PM +0100, Xavier Beaudouin wrote: > > To move the temporary file, you need to delete the current > > courierpop3dsizelist before. > > In this case, what is happen if another pop3d process try to access > > between the delete and the move. > > Good question... For me this case, this is what I can call race.
There is no delete [unlink], just a rename() call. Look in imap/pop3dserver.c function savepop3dlist(). > On some NFS client (not server) : rename is atomic, but remove (delete) > can be atomic or not, > appending gets the same problems as well. > > Yeah I agree that *some* opensource NFS client (Linux, FreeBSD for > example) gets such call > as atomic, but on Solaris, for example, _only_ rename is atomic, > because OS cache read / append > into its local VFS cache before commiting on the NFS server... Sam's code only does a rename, so there is no problem. Each client will see either the old version of the file, or the new one. It's not critical which version they see. > Caching in files maybe a good idea, we have moved the cache from NFS to > local cache on disk, > this give us same functionality and avoid some race conditions. That would be fine for courierpop3dsizelist. It's not so much use for the maildirsize file, which has to be shared between all the front-ends or else it doesn't work at all. Rewriting maildirsize *does* have some race conditions, in the sense that the calculated quota size may not always be entirely accurate. It's a trade-off between efficiency/overhead and functionality. Regards, Brian. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
