... chad wrote: > > Spitballing for a moment: I wonder if we can detect the case where > the sequence file changes out from under an operation. If so, it > might be possible to save the original data, compute a delta of > some sort, and use that to repair the sequence, or punt to the user?
http://www.youtube.com/watch?v=rSBNT5WKizg > I used to see this problem (rarely) with a periodic fetchmail+slocal > setup, and 'folder -pack' was almost always enough to make the world > right. On the other end, things like rsync, hg, and git have advanced > the state of the art in version-skew management a fair bit since > those days. > > Just an idea; I hope it helps. sometimes we get logjammed on hard problems and have to figure out what "the MH way" is in this case. i know that the MH way is not "corrupt the .sequence file so that all subsequent MH commands fail with an error message" and that's why i sent the patch in 2003 that made rcvstore use the locking version of fopen rather than the raw libc fopen. however i don't think the MH way is "compute a delta of some sort". i propose that the locking fopen function in the MH library be adapted to be willing to try the advisory lock three times at one second intervals, on the assumption that no writer will hold the lock that long and if there's a convoy then we've got bigger problems. (ideally we'd do a wait-lock in a thread and kill that thread if it waits too long, but threads would not be "the MH way".) paul
_______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
