Date: Wed, 15 Aug 2001 12:40:40 +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: <2561-Wed15Aug2001124039+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: <10108150556.AA15511@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: Win2000 _open hack, rev 2 - working prototype
References:  <10108150556 DOT AA15511 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: Wed, 15 Aug 2001 00:56:45 -0500 (CDT)
> 
> 1) If SFN available from 7160 we use it.
> 2) If SFN name create fails, try LFN _chmod call to see if exists
>    (this will also show existence of devices on Win2K)
> 3) If exists try to open with name using SFN interrupt.  This should
>    handle NUL, /dev/null (translated to NUL) or CON, etc.
> 4) If fail, just use LFN open call.  This will then succeed for 
>    ./nul (or any-existing-directory/nul) for checking existence.  If 
>    anyone fstat() the handle or dev info it it will be bogus, but this 
>    is our last shot.  Note, if they call access instead we should be OK.
> 
> fstat() on the handles from this code look good, as do dev info calls.
> What do you guys think?

I think it's such a definite improvement compared to what we have now,
that it's a good candidate to be tested with a variety of applications
and scripts, to see whether the issue with the last-resort LFN open of
./nul and the like is a problem in practice (I'd hope it isn't).

> I can re-write this tomorrow for review if it seems sound.

Please do.

> +     } else {
> +       /* If it failed, either file doesn't exist or is device */
> +       printf("Tried 7160 on \"%s\" and it failed (%d).\n",filename,r.x.ax);

Should we perhaps examine the error code in r.x.ax here, and be a bit
more discriminate?

Last but not least: I just had my last-minute doubts: doesn't an SFN
open nuke the long file name if we open the file for writing?  Can you
test that (if you didn't already), in particular with O_TRUNC?