Date: Sat, 25 Aug 2001 19:12:48 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: sandmann AT clio DOT rice DOT edu Message-Id: <5567-Sat25Aug2001191247+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9 CC: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com In-reply-to: <10108251459.AA17702@clio.rice.edu> (sandmann@clio.rice.edu) Subject: Re: Read 3F00 STDIN problem on Win 2K ( was Re: Fseek on STDIN problem on Win 2K) References: <10108251459 DOT AA17702 AT clio DOT rice DOT edu> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) > Date: Sat, 25 Aug 2001 09:59:45 -0500 (CDT) > > 3) This problem is masked on 2.03 due to call sequences which are different > (when using fstat, no one calls the get magic manually). ??? What do you mean by that? fstat _always_ tries to get the magic number if the handle refers to a file (not a character device). > 4) This problem is masked on 2.04 if lfn=n due to call sequence differences > (when using fstat). And just to be sure we are talking about the same issue: by ``this problem'' do you mean the weird behvaior of read and lseek wrt file position? Or is there anything else? > What I think, but must be confirmed: > 1) This problem is only seen on handle 0 when opened by NT, not Bash I think you saw similar problems on handle 1. The current hypothesis is that any handle opened by the NT shell will behave like that, which means handles 0-4 could potentially be affected. > Tests I'd like to see first: > 1) Does this happen on any handles opened with libc? If not then let's > narrow any tests in the future to handle 0,1,2,3,4 at worst. > 2) Does this happen on any handle which _get_dev_info is not 0? > 3) Does seek on pipes work? For example, prog1 | prog2 - lets say that > prog1 dumps 10 Megabytes down the pipe, can we reliably seek anyplace, > anytime in that 10Mb? I know that limited seeks *DO* work, for example > "dir | test" shows the magic as " V" and then is off by two chars. But > if I do the fix I can go back the two characters in the pipe. But how > far can I go? Should pipes really be marked executable? > 4) Does rebuilt patch work on stdin() if built using a patched 2.03? > 5) Does rebuilt patch work on stdin() if you force ISREG to be false? Sounds like a good plan to me. But if an extra seek solves the problem, why not try use it? We could make it part of this testing as well, to see whether it indeed solves the problems. > A similar problem is seen when redirecting from NUL for example - this is > shown as a regular file. We shouldn't be seeking on NUL, or reading > magic numbers, but we do today. We seek on NUL because we don't know it's a character device.