From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108221532.AA12511@clio.rice.edu>
Subject: Re: Fseek on STDIN problem on Win 2K
To: eliz AT is DOT elta DOT co DOT il
Date: Wed, 22 Aug 2001 10:32:11 -0500 (CDT)
Cc: acottrel AT ihug DOT com DOT au, djgpp-workers AT delorie DOT com
In-Reply-To: <200108221430.KAA02730@delorie.com> from "Eli Zaretskii" at Aug 22, 2001 10:30:24 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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

> It looks like 4200 reports that it did move the file pointer, but the
> subsequent 3F00 still continues from the position before the lseek.

Yes, it appears NT has cached the location of the pointer (incorrectly)
and treats the a second call to set the absolute pointer position to
the same place as the previous call a no-operation.  A get of the pointer
or a move to a different location fixes it.

> Right now, I'm more worried by lseek not working than by
> _is_executable.  I think we need first to find a good general-purpose
> solution for lseek, so that we could be sure the file pointer moves to
> the right place.  If that doesn't fix _is_executable, we can find some
> local trick later.

Agreed. So far in testing, doing a 4201 call with zero relative offset
(i.e. get position) seems to fix it.  Probably putting this call in
_is_executable (and maybe lseek) would fix the problems.  Or we make 
the handle a pipe :-)  

> Thanks, trying this with different shells might indeed shed some light
> on this problem.

This problem does not happen under bash on NT4.0.  This indicates to me
even more the problem is only on NT opened handles.

I'll repeat that handles on NT can be real pipes also, and I don't 
know how well seeking is supported on larger inputs.  Pipes also have
the get_dev_info to be zero - so today we don't show a difference.

Also remember, that NT 4.0 and DJGPP have co-existed for 5 years, and
no one has reported this until now, so it's probably not a crisis to
fix it immediately.  Using bash is a workaround.