bug-rcs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug #41707: RCS 5.8 file corruption when using file descriptor IO fo


From: Thien-Thi Nguyen
Subject: Re: bug #41707: RCS 5.8 file corruption when using file descriptor IO for large files
Date: Mon, 28 Jul 2014 06:18:04 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

() Achim Gratz <address@hidden>
() Sun, 27 Jul 2014 17:49:43 +0200

   I'll check this, but at the moment can't say
   when I'll have time to do that.

You sent another message after this, but i accidentally deleted it,
thinking to read it in the bug-rcs archives.  But strangely, all of
this thread is missing:

 http://mail.gnu.org/archive/html/bug-rcs/

Last post was in June.  Hmm.  Could you please resend it?  (In this
reply, i reverse To and Cc contents, let's see what happens.)

   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.

Yes.

   I'm not sure what guarantees POSIX makes w.r.t. shared
   filehandles and stream operations across a fork.

Does Cygwin have anything particular to say about this?

   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.

I understand everything except for "unclean".  What does that mean?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]