Date:	Sat, 25 Aug 2001 19:12:48 +0300
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
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

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

- Raw text -