Mail Archives: djgpp-workers/2001/08/07/13:30:45
> From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
> Date: Tue, 7 Aug 2001 21:43:20 +1000
>
> 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?
> 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.
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.
- Raw text -