X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        bh=OjVdW1UGyfhyUco6mdIHAUWK2zfK/Ge1ubtAJmdaLko=;
        b=NQ5fB/Xxswegj4oJhtC1CNA463bkABgoDtdTNHeTVZLfZznKoKVcVzogsx8tetJzGA
         ibj7JtTZs2BM2PVmFV+hKzxjn5+k2QNWJZZAwwM8SHzrEx/kSXffSF8qHvzNdjNwMOu9
         PG7h40txeFFl6VSpWHVBRwXj4rnwNvHfe1n70=
MIME-Version: 1.0
In-Reply-To: <9a4f248a-9734-4f4e-b06c-db4b9960a7d4@hb5g2000vbb.googlegroups.com>
References: <201109101340 DOT 47663 DOT juan DOT guerrero AT gmx DOT de>
	<83vct04a4x DOT fsf AT gnu DOT org>
	<CAA2C=vBkMD34-KBtp0hMbQ3Ppk8gavXJjkddDq_2hjzUA7PYHA AT mail DOT gmail DOT com>
	<9a4f248a-9734-4f4e-b06c-db4b9960a7d4 AT hb5g2000vbb DOT googlegroups DOT com>
Date: Thu, 15 Sep 2011 19:19:34 +0300
Message-ID: <CAA2C=vBfbqzh_dZwW41EH2iNyN2ub7Hyufnqv7pvQ5NJzLf=ug@mail.gmail.com>
Subject: Re: Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS
 (0x71XX) implementation.
From: Ozkan Sezer <sezeroz AT gmail DOT com>
To: djgpp AT delorie DOT com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id p8FGJdXo000742
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Thu, Sep 15, 2011 at 7:08 PM, Juan Manuel Guerrero
<juan DOT guerrero AT gmx DOT de> wrote:
> 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 on
> week end.
>

Thanks.

>> 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) ?
>
> A question of preference, I assume.  I use only 2.04
>

OK, thanks.

>
> Regards,
> Juan M. Guerrero
>
>

--
O.S.