From:	sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id:	<10108221941.AA14151@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 14:41:04 -0500 (CDT)
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<4098-Wed22Aug2001221113+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 22, 2001 10:11:14 PM
X-Mailer:	ELM [version 2.5 PL2]
Mime-Version:	1.0
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

> > If get_dev_info returns zero and OS is NT, 99% of the time this will
> > be a pipe or weird handle.
>
> I'm not sure we know enough to rely on that.  You effectively rely on
> a bug to tell you something very specific about the handle.

Up to this point we have been talking about seeking on STDIN (does the
2.03 library not call the is_executable?  fstat() doesn't cause this
problem in 2.03 which might explain why it's more rare).

I tried test >> testout
I tried test >> nul

fstat() is OK with handle 1, in both cases thinks it's a file, lseek
says it's at the beginning (0) wrong for file append.  First example
gets the right size in fstat, second example says it is zero length.
Both examples return times (first example is file time, second example
is weird date in future).  In both cases _read fails on the handle.

So, what about seeking on outlet handles?  It doesn't work, but
the dev_info looks identical.

It seems to me if dev_info is zero for a pre-opended handle on NT we
should be very careful - just modifying magic_num and seek is a partial
fix.

Proposal:  fstat() (or dev info?) does the following:
  if dev_info == 0 and NT and handlenumb <5 dev_info = 0x8000

So it appears as a char device instead of a file.  Only ambigous
for redirect from a floppy, and treating those as a character 
device is probably a good optimization :-)

- Raw text -