Mail Archives: djgpp-workers/2001/08/08/07:57:41
> > 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?
- Raw text -