X-Authentication-Warning: new-smtp1.ihug.com.au: Host p40-max50.syd.ihug.com.au [203.173.144.168] claimed to be acceleron Message-ID: <007601c12000$30d8adc0$0a02a8c0@acceleron> From: "Andrew Cottrell" To: "Eli Zaretskii" , "Charles Sandmann" Cc: References: <012401c11f40$19d063e0$0a02a8c0 AT acceleron> <9003-Tue07Aug2001202952+0300-eliz AT is DOT elta DOT co DOT il> Subject: Re: Fw: Windows 2000 /dev/null permission query Date: Wed, 8 Aug 2001 21:49:31 +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 > > 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. > > To see if these values are okay, I need to know the file's times as > reported by some independent program. Can someone suggest a way to > print the 3 file times up to the last bit of accuracy using some Win32 > application? I have used some example source code from VC++ to write an app to display the following: DJGPP_204 D:\work\filetime\Debug>filetime create high = 0x01C11FFA create low = 0xF8AE6C80 access high = 0x01C11FFA access low = 0xF8AFF3B0 write high = 0x01C12EF7 write low = 0xDCD79400 FILE TIME 10:57:44 PM new.txt Achnrst 4 byte(s) Created : 08/08/01 21:12:11 Last Access: 08/08/01 21:12:11 Last Write : 08/27/01 22:57:44 The windows app uses the FILETIME structure is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601. So it I then re-ran the test app, but the results are not the same should they be? DJGPP_204 D:\work\filetime\Debug>touch 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 = 0x30000 uniq_id_low = 0x890A > > 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? > > We should at least test each LFN function called by the library. We > should do that for both regular files and devices. We should also try > functions, whether from the LFN API or not, which accept a handle, > since we already know they might be broken for handles created by > 716C. I will start to prepare a series of tests on the weekend that we can use to verify each of the LFN functions used by LIBC. > Since IOCTL is broken on W2K, we probably should decide how to fix > that (see my other mail), and then begin fixing it. The first step > would be to prepare a list of IOCTL subfunctions called by the library > and rgeir callers; the next step is to see whether all the IOCTL > subfunctions are broken or only some. I need to do some background reading about this to get up to speed. By IOCTL are we talking about 44xx calls?