From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10108131551.AA16903@clio.rice.edu>
Subject: Re: Windows 2000 io testing
To: eliz AT is DOT elta DOT co DOT il
Date: Mon, 13 Aug 2001 10:51:39 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <1190-Mon13Aug2001131540+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Aug 13, 2001 01:15:41 PM
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

> > 5) _chmod (__file_exists) is true with lfn active on devices, returns 0x20
> >    (this is different than w95 for example).
> 
> Windows 9X should return 0x40; is that what you see?

Actually Win 95 fails (returns -1) on nul or con

> Also, is findfirst consistent with _chmod for devices, i.e. does it
> also return 0x20 in the attribute byte?

Didn't play with findfirst yet.  Will test.

> > 8) _get_dev_info looks ok for pre-opened handles
> Does this mean the 5 preopen handles each program gets from the shell?

Yes.

> If so, did you try that under Bash as well?  

Did not try under Bash.

> What happens with handles beyond the 5 standard ones, which are open in a
> parent program--can the child successfully call _get_dev_info for those?

If they were opened with SFN calls - yes.
If they were opened with LFN calls - no.

But we don't have code (that I know of, maybe you have an idea) which
would look at the text string for file to open and know before trying
if it is a device or not.

> And does isatty work on preopen handles as well?

Didn't test, but I expect it will since _get_dev_info is OK.

> It would also be interesting to see what happens if a DJGPP program
> uses an LFN open call to open a device, such as CON or NUL, then sets
> one of the standard handles to the same device with dup2 and spawns a
> child.  Do _get_dev_info and isatty work then on those inherited
> handles?

Eyes glazed over.

> > So far I've been unable to get an _open working reliably on all cases.
> > Using lfn opens is actually more compatible (you can test directory
> > existence).
> 
> Sorry, I don't follow: how does the LFN open helps testing for
> directory existence?

I was using ./nul as a directory existence check.

> > 4) sfn open fails on ./nul but works on nul (consistent with _truename)
> 
> One other thing: what about c:/foo/bar/nul (where the leading
> directories do exist)?

I need to double check what happens when directories don't exist, but 
if directories exist this works with LFN handles but fails with SFN
handles.

Summary:
So, if someone wants to check a directory existence, we would want to
use a LFN handle.  But then it's _get_dev_info would be bogus(=0), and
fstat would fail.

If someone wants to write to /dev/null we would want to use a SFN
handle, _get_dev_info, write(0), and fstat would be happy.

How much code actually opens devices (nul,con,aux,prn) instead of using
pre-opened handles?  When they do, what calls need to be supported?