X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Authenticated:	#27081556
X-Provags-ID:	V01U2FsdGVkX1+AoUpgAUuA6SeeNBBWR5d7LpY+85+alxpo+6V3QX
	yRpXrJdw6zVHMf
From:	Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
To:	djgpp AT delorie DOT com
Subject:	Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX) implementation.
Date:	Sat, 10 Sep 2011 13:40:47 +0200
User-Agent:	KMail/1.9.10
MIME-Version:	1.0
Message-Id:	<201109101340.47663.juan.guerrero@gmx.de>
X-Y-GMX-Trusted:	0

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.

I have already patched all functions so that the CF is always set before
calling 0x71XX.  Now, the question arises how to proceed when it is detected
that the required 0x71XX function is not available.  Especialy if renaming or
deleting functions are used.  E.g., shall remove really remove a SFN file if
it does not find the LFN file because the LFN API function is not available?
Is the relationship between SFN and LFN really always unique?  Shall we really
rename a file using SFN API if LFN API is not available?  Other functions like
filelen, _creat and findfirs/findnext are less critical.
It would also be possible to improve _use_lfn() to check for _all_ 0x71XX
functions.

The questions is shall we use the corresponding SFN API function if the LFN API
function is not available, risking to corrupt the file and/or the file system?

Any suggestions will be welcome?


Regards,
Juan M. Guerrero



libc/ansi/stdio/remove.c       0x713A, 0x7141
libc/ansi/stdio/_rename.c      0x7156
libc/dos/dir/findfirs.c        0x714e, 0x71a1
libc/dos/dir/findnext.c        0x714f, 0x71a1
libc/dos/dos/truename.c        0x7160
libc/dos/io/flushdc.c          0x710d
libc/dos/io/_chmod.c           0x7143
libc/dos/io/_creat.c           0x716c
libc/dos/io/_creat_n.c         0x716c
libc/dos/io/_open.c            0x7143, 0x7160, 0x716c
libc/dos/lfn/lfnshort.c        0x7100, 0x71a8
libc/dos/lfn/_use_lfn.c        0x7100, 0x71a0
libc/dos/process/dosexec.c     0x7160
libc/posix/dirent/opendir.c    0x71a1
libc/posix/sys/stat/fchmod.c   0x71a6
libc/posix/sys/stat/filelen.c  0x71A6
libc/posix/sys/stat/fixpath.c  0x7147, 0x7160, 0x713b
libc/posix/sys/stat/fstat.c    0x71a6
libc/posix/sys/stat/lfilelen.c 0x71A6
libc/posix/sys/stat/mkdir.c    0x7139
libc/posix/unistd/chdir.c      0x713b
libc/posix/unistd/getcwd.c     0x7147
libc/posix/unistd/getcwd.c     0x7160
libc/posix/unistd/rmdir.c      0x713a
libc/posix/utime/utime.c       0x7143

- Raw text -