Mail Archives: djgpp-workers/2018/05/17/16:30:51
Am 07.05.2018 17:48, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com]:
> On 05/06/2018 10:53 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-workers AT delorie DOT com] wrote:
>> Am 05.05.2018 16:04, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp-workers AT delorie DOT com]:
>
>>> It is easy to test with any simple test program that tries to open file with LFN preasent and SFN missing.
>>>
>>> 1) disable SFN creating according to Microsoft instructions and reboot. It will not affect any already existing file for which SFN is already present
>>> (https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions)
>>> 2) create some file lite test.file.1 (you can even do it with DJGPP tools as creating file works)
>>> 3) reenable SFN creating in registry and reboot to prevent problems with files created later
>>>
>>> After that You have a test file with missing SFN (one can try 'LFN=N ls -l' to verify that SFN is missing.
>>> 'cat test.file.1' is after that expected to fail. For debugging plain opening file for reading is sufficient for testing.
>>>
>>> Andris
>>
>> OK, I was able to reproduce this for Win2K and WinXP when they read/write on NTFS formated partitions.
>> Have you already designed any fix for this issue? Is there any fix conceivable for this issue when
>> only long filenames have been created? IIRC on FAT file systems the short file name is created first
>> and then the long file name is assigned to it. A long file name without a short filename does not exist,
>> or am I missing something?
>>
>
> It seems that DJGPP mailing list has at least partial fix:
>
> http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2016/05/14/13:45:09
>
> Patch was intended for exFAT which seems to not have SFN either. It works also for NTFS.
> (I had file around with SFN missing on Windows Vista Business 32-bit SP3 and did not remove it to have something for testing on NTFS)
>
> Andris
>
>
I have checked very carefully all LFN functions that use function 0x71NN
and there are no pending issues. The proposed patch fully fixes the issue
and has no side effects at all. This means that all functions: open, close,
rename and unlink do flawlessly work when no SFN is available. This is true
for Win2K and WinXP. I have no chance to check exFAT nor other OSs like
Vista and above. I am aware that I have claimed that there were still some
pending issues, but that was not true. It was a bug in my test program.
If no one rises really serious objections I will commite the patch below
in a couple of hours. It makes no sense to wait more time to fix this issue.
The issue concerning the call of the system function is something completely
different and cannot be fixed at all. In the end, the call of system()
issues a call of INT21 0x4B00. One of the arguments passed to function
0x4B00 is the full path of the program to be started and this path and the
file name must be a valid DOS path and file name. This means that the file
name must be a valid 8.3 file name and the path length is not allowed to
exceed the max. length of a DOS path (IIRC 64 characters). I have compiled
a library with a modified version of dosexec.c:direct_exec_tail_1 that always
supplies the LFN versions of the path and the file name to function 0x4B00.
With this library I have compiled a test program that has been run on
MSDOS 6.22 with LFN driver installed, on Win98SE, on Win2K and on WinXP
and the program fails to start a LFN program. On the different windows
versions, a call of 0x4B00 with LFNs fails with a file not found (ENOENT)
error and on MSDOS it simple hangs the machine. I have not investigated
this any further because it is of no interest at all. The bottom line is
that as long as function 0x4B00 is used to start another program, the path
to the program must be a valid DOS path or it will not work. 0x4B00 does
not support anything else. I have not inspected the code of the spawn*
family of functions but I assume that in the end they also use 0x4BNN
functions, so there is no way to start a program that has no valid LFN
alias.
IMO, having seen what is possible to fix and what can never be fixed,
it is time to define the next steps to a DJGPP 2.06 release.
Regards,
Juan M. Guerrero
* djgpp/src/libc/dos/io/_open.c: Support file systems that do not provide SFN aliases for file names.
Patch provided by Wiktor S. (wswiktorSP AT Mpoczta DOT fm).
* djgpp/src/docs/kb/wc206.txi: Support file systems that do not provide SFN aliases.
Index: djgpp/src/docs/kb/wc206.txi
===================================================================
RCS file: /cvs/djgpp/djgpp/src/docs/kb/wc206.txi,v
retrieving revision 1.11
diff -p -U 5 -r1.11 wc206.txi
--- djgpp/src/docs/kb/wc206.txi 2 Feb 2018 20:00:05 -0000 1.11
+++ djgpp/src/docs/kb/wc206.txi 17 May 2018 19:53:35 -0000
@@ -53,5 +53,10 @@ The low-level @code{_put_path} procedure
[/\\]dev[/\\] instead of only /dev/ in file names.
@cindex Compatibility with new gcc versions
Compatibility with gcc-6 and newer versions achieved by using proper
@option{-fno-builtin-*} compiler flags where needed in library builds.
+
+@findex open AT r{, and failure on file systems without SFN alias}
+@code{open} will no longer fail when trying to open a file that has no
+short file name alias. This used to happen for the NTFS and the exFAT
+file systems.
Index: djgpp/src/libc/dos/io/_open.c
===================================================================
RCS file: /cvs/djgpp/djgpp/src/libc/dos/io/_open.c,v
retrieving revision 1.12
diff -p -U 5 -r1.12 _open.c
--- djgpp/src/libc/dos/io/_open.c 12 Mar 2014 22:58:31 -0000 1.12
+++ djgpp/src/libc/dos/io/_open.c 17 May 2018 19:53:36 -0000
@@ -1,5 +1,6 @@
+/* Copyright (C) 2018 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2014 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2011 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2002 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 2001 DJ Delorie, see COPYING.DJ for details */
/* Copyright (C) 1996 DJ Delorie, see COPYING.DJ for details */
@@ -15,16 +16,21 @@
#include <dos.h>
#include <libc/dosio.h>
#include <sys/fsext.h>
#include <libc/fsexthlp.h>
+typedef enum {
+ false = 0, true = 1
+} bool;
+
int
_open(const char* filename, int oflag)
{
__dpmi_regs r;
int rv;
int use_lfn = _USE_LFN;
+ bool retry_with_lfn = false;
if (filename == 0)
{
errno = EINVAL;
return -1;
@@ -48,10 +54,11 @@ _open(const char* filename, int oflag)
r.x.es = __tb_segment;
r.x.di = __tb_offset + _put_path(filename); /* Short name destination */
__dpmi_int(0x21, &r);
if (!(r.x.flags & 1)) /* Get short name success */
{
+ retry_with_lfn = true;
r.x.ax = 0x6c00;
r.x.bx = (oflag & 0xff);
r.x.dx = 1; /* Open existing file */
r.x.si = r.x.di;
goto do_open;
@@ -81,10 +88,11 @@ _open(const char* filename, int oflag)
Permission? Readonly file? We should quit.
Let it fall through to the LFN open which should succeed. */
}
}
}
+fallback:
if (use_lfn)
{
r.x.flags = 1; /* Always set CF before calling a 0x71NN function. */
r.x.ax = 0x716c;
r.x.bx = (oflag & 0xff);
@@ -134,10 +142,19 @@ do_open:
r.x.dx = __tb_offset;
goto do_open;
}
else if (r.x.flags & 1)
{
+ if ((r.x.ax == 2 || r.x.ax == 3) && retry_with_lfn)
+ {
+ /* On partitions like NTFS and exFAT, files and paths with long names
+ do not have 8.3 aliases. If an attempt to open the file with short
+ name failed with "file not found" or "path not found", retry with
+ the LFN API. */
+ retry_with_lfn = false;
+ goto fallback;
+ }
errno = __doserr_to_errno(r.x.ax);
return -1;
}
do_hset:
__file_handle_set(r.x.ax, O_BINARY);
- Raw text -