Re: bug #41707: RCS 5.8 file corruption when using file descriptor IO for large files
Achim Gratz <[email protected]> Sun, 27 Jul 2014 17:49:43 +0200
| Newsgroups | gmane.comp.version-control.rcs.bugs |
|---|---|
| Organization | Linux Private Site |
| Message-ID | <[email protected]> |
Thien-Thi Nguyen writes: > - I have rewritten the test, attached here, to be more idiomatic. > > The first step is to check that this test fails for you when > unpatched, and passes when patched. Could you please confirm? > (NB the ??? re ‘need_subdir’.) The "maybe" in the description > is because there was no way for 5.7 to force STDIO operation, > so the problem might have been latent at that time. I'll check this, but at the moment can't say when I'll have time to do that. As for the subdir I don't think it matters since the first version of my test didn't use it. I'll test it again, though. > - I'm wary of adding the close/re-open sequence unconditionally and > wonder if there is a way to detect systems that misbehave thusly > with a short C program (or better yet, sequence of shell > commands) to be run by the configure script. What do you think? I haven't had the time to reduce this to a deomstrator, but once we have that it'd be possible to use the result in configure. > - etc > > It's probably best to worry about "etc" after we surmount these > first two steps. I understand that there is a difference between > GNU/Linux (say) and Cygwin, but i don't understand (yet) if that > difference is legitimate (i.e., allowed by POSIX or other relevant > standards). What do you suggest i read to understand the analysis > linked in the URL above? I'm not sure what guarantees POSIX makes w.r.t. shared filehandles and stream operations across a fork. The conditions that trigger the bug seem to be that one must have a stream associated to a filehandle, already read from that stream so the buffer gets filled (and the stream is unclean), then fork with that filehandle still open and read to EOF on the child process, then try to read past the end of the buffer in the parent process. The immediate problem seems to be that the filehandle in the parent process still sees the EOF condition that the read in the child has produced. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada