Mail Archives: djgpp/2011/09/15/12:30:09
On 15 Sep., 11:48, Ozkan Sezer <seze DOT DOT DOT AT gmail DOT com> wrote:
> On Sat, Sep 10, 2011 at 7:47 PM, Eli Zaretskii <e DOT DOT DOT AT gnu DOT org> wrote:
> >> From: Juan Manuel Guerrero <juan DOT guerr DOT DOT DOT AT gmx DOT de>
> >> Date: Sat, 10 Sep 2011 13:40:47 +0200
>
> >> I have checked the repository and found that the following functions use the
> >> INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX). Accoring to RBIL61, the
> >> recommended way to proceed here is always to set CF before calling a 0x71XX
> >> function, and after the function call has been performed to check that the
> >> AX register does not contain 0x7100. If AX == 0x7100 the functionality is not
> >> provided by the LFN API and the corresponding SFN API function shall be called.
>
> >> Not a single of the functions set CF before calling 0x71 functions. This can
> >> produce serious malfunctions as has been seen with MSDOS 6.22 and DOSLFN 0.40e
> >> in threat <httpdjgpp/2011/08/30/18:59:04>
> >> Except for _use_lfn and lfnshort not a single function checks for AX != 0x7100.
> >> This is certainly wrong and makes a lot of programs fail (e.g., gcc, gdb, grep).
> >> Some of these functions call _use_lfn to decide if LFN support is available or
> >> not, but _use_lfn only checks for 0x71a0 and this is certainly not enough to
> >> decide if the required 0x71XX functions are really available or not.
>
> > The assumption was that LFN functions are either all supported or not
> > at all. If that assumption is not true, by and large, then many
> > things will fall apart.
>
> >> shall remove really remove a SFN file if
> >> it does not find the LFN file because the LFN API function is not available?
>
> > No! It should simply fail. If some environment supports 0x71a0, but
> > does not support 0x7156, then it basically means LFN is not supported,
> > and the user will have to disable LFN through the environment
> > variable.
>
> > The same goes for `_rename' and other basic functions that accept file
> > names as their arguments, and make destructive changes to the
> > filesystem.
>
> > Functions that accept file descriptors, by contrast, could fall back
> > on SFN functions where that makes sense, i.e., where some useful data
> > can be still returned to the caller.
>
> >> It would also be possible to improve _use_lfn() to check for _all_ 0x71XX
> >> functions.
>
> > That would make it painfully slow, which is not a good idea, because
> > as I recall it is called internally by many library functions. Don't
> > forget that calling any Int 21H function requires an expensive mode
> > switch. It is better to add recovery to the few functions we found
> > now to be not supported well by DOSLFN.
>
> > Below are my suggestions for the functions you mentioned:
>
> > libc/ansi/stdio/remove.c 0x713A, 0x7141 -- fail
> > libc/ansi/stdio/_rename.c 0x7156 -- fail
> > libc/dos/dir/findfirs.c 0x714e, 0x71a1 -- fail for 0x714e
> > libc/dos/dir/findnext.c 0x714f, 0x71a1 -- fail for 0x714f
> > libc/dos/dos/truename.c 0x7160 -- fall back on 0x6000
> > libc/dos/io/flushdc.c 0x710d -- fall back on BIOS DISK RESET
> > libc/dos/io/_chmod.c 0x7143 -- fail
> > libc/dos/io/_creat.c 0x716c -- fall back on SFN
> > libc/dos/io/_creat_n.c 0x716c -- fall back on SFN
> > libc/dos/io/_open.c 0x7143, 0x7160, 0x716c -- fall back on SFN
> > libc/dos/lfn/lfnshort.c 0x7100, 0x71a8 -- fall back on SFN
> > libc/dos/lfn/_use_lfn.c 0x7100, 0x71a0 -- return 0
> > libc/dos/process/dosexec.c 0x7160 -- ignore
> > libc/posix/dirent/opendir.c 0x71a1 -- ignore
> > libc/posix/sys/stat/fchmod.c 0x71a6 -- already handles this
> > libc/posix/sys/stat/filelen.c 0x71A6 -- fall back on 0x42XX
> > libc/posix/sys/stat/fixpath.c 0x7147, 0x7160, 0x713b -- fall back on 0x4700
> > libc/posix/sys/stat/fstat.c 0x71a6 -- already handles
> > libc/posix/sys/stat/lfilelen.c 0x71A6 -- already handles
> > libc/posix/sys/stat/mkdir.c 0x7139 -- fall back on 0x3900
> > libc/posix/unistd/chdir.c 0x713b -- fall back on 0x3b00
> > libc/posix/unistd/getcwd.c 0x7147 -- fall back on 0x4700
> > libc/posix/unistd/getcwd.c 0x7160 -- already handles
> > libc/posix/unistd/rmdir.c 0x713a -- fail
> > libc/posix/utime/utime.c 0x7143 -- only uses 0x7143 on NT/2K/XP
>
> What is the status of this issue?
I am working on this. Be patient. I think I will post a patch at
week end.
> On a related note which of v2.03r2 and v2.04-20110904 is
> more suitable for use (with or without the above LFN issues
> addressed) ?
It is a question of preference I assume. I use only 2.04
Regards,
Juan M. Guerrero
- Raw text -