X-Authentication-Warning: new-smtp1.ihug.com.au: Host p31-max47.syd.ihug.com.au [203.173.145.31] claimed to be acceleron
Message-ID: <012401c11f40$19d063e0$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>
Subject: Fw: Windows 2000 /dev/null permission query
Date: Tue, 7 Aug 2001 21:43:20 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Reply-To: djgpp-workers AT delorie DOT com


> > On Mon, 6 Aug 2001, Charles Sandmann wrote:
> >
> > > > > > Another idea might be to use `dup' to duplicate a handle from an
> LFN
> > > > > > open call, then see if that handle has the same problems with
> function
> > > > > > 5701 as the original handle.  (Since `dup' doesn't have an LFN
> analog,
> > > > > > maybe the duplicated handle is created as a non-LFN one, who
> knows?)
> > >
> > > >  Not tested. Tomorrow
> > >
> > > Don't bother - dup doesn't help, it continues to fail.
> >
> > I was afraid of this, sigh...  That was a wild guess anyway.
> >
> > > I haven't tried creates - I don't know if their LFN handles fail.  If
so
> > > I guess we create LFN/close get short name open short?  Yuk.  Sigh.
> >
> > However yucky, this might be a solution, but only if we find that SFN
> > handles don't fail any handle-related calls that are part of the LFN
> > API.  For example, what about function 71A6h?  (The Microsoft LFN API
> > document does seem to specify that all LFN handle-related functions
> > should work for handles created by function 6Ch, so there is hope.)
> >
> The call to 71A6 returns the following data if passed the file handle from
> 6C00h or 3Dh. I do not have any code to decipher the results, except the
> length of the file which is correct.
>
> DJGPP_204 D:\dj204\contrib\touch>test
> -rw-r--r--   1 AC       root            4 Aug 25  2001 new.txt
> file_attrib = 0x0020
> creation_time_h = 0x20626972
> creation_time_l = 0x6E6F6974
> access_time_h =  0x206C5F65
> access_time_l =  0x32783020
> write_time_h =  0xD303230
> write_time_l =  0x33323330
> hd_serial =  0x84950A0A
> retval_l =  0x0004
> retval_h =  0x0000
> links =  0x0001
> uniq_id_high =  0x80000
> uniq_id_low =  0x88E0
>
> Hope this helps.
>
> Now for the next hard questions:
> What is the consensus as to the way to head on fixing the LFN issues on
> Win2K?
> Do we fix on a case by case basis for each of the file I/O functions that
> fail?
> Test each of the LFN API function calls and then make a descision on what
to
> do next? May take some time to do, but would be very advantageous for
> testing on all Windows variations (95,98,98SE,ME,NT 4.0 SP x, 2K SP x, XP
RC
> x where x = TBA).
>
> My feeling is to write a series of test programs to check the LFN API and
> include a Windows app that produces a set of results that is then  used to
> check the test programs to see if the API passed or failed. This assums
that
> the API function passed, but the data is not correct. I wonder how many of
> the LFN API will give wrong data....