...
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
|