>Is this a problem for nmh? I don't think so. Here's what >we do in context_save(): > > if (!(out = lkfopen (ctxpath, "w"))) adios (/* not shown */); > /* write the context to the file */ > lkfclose (out, ctxpath);
Well, this gets into something ELSE I wanted to bring up. As discussed, this prevents sequence file corruption, but doesn't solve the race condition you can get with rcvstore. So it occurs to me that we should really solve that properly. Solving THAT means that we have to lock the sequence file across a read()-change-write() cycle. How we implement that is up in the air; right now that happens as part of folder_read(), and sticking a write lock in there seems wrong. But we could make functions that want to update a sequence call seq_read() again to a) write lock the sequence file(), and b) re-read the sequence file to update the folder structure with any changes. That would mean keeping around a file descriptor longer (but not too much longer, hopefully). >We could change the current configure --with-locking to not >apply to the spool file lock. For that, and the nmh state >file locks unless overridden, use what configure now picks >for the default lock method. In other words, --with-locking >would only apply to the nmh state files. I think that >agrees with what Lyndon suggested, putting aside the default >lock method choice. See, I was thinking the exact opposite; I think people think now that --with-locking applies to spool files. But irregardless, I am thinking that we should be switching to run-time configuration as much as possible. Maybe --with-locking could set the default spool locking for a platform. >Would the added steps in [] below help? > > open file, lock file, read file, unlock file, close file > [save entire file contents] > update sequences > open file, lock file > [read file] > [compare current file contents to saved file contents: > if the same, then write file > if not the same, then complain and leave file as is] > unlock file, close file > >The user could see that there was a collision and wouldn't have >mangled files. See, I don't think this is necessary. A brief look at the relevant programs suggests to me that with a few API tweaks we can actually maintain consistent locking across sequence files and (in most cases) the locking window will be rather small. Context files are a bit harder, but I'm not sure that's as critical; the information there isn't (generally) a large set being modified by multiple programs at once. I think we can live with just open/lock/write/close sequence there. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
