Truename returns incorrect results with device nul

[andrewbird]

Whilst debugging an issue with FreeDOS, I found it necessary to write a test to examine Truename. Strangely things were fine with the FreeDOS kernel in git (though 1.2,1.3 were broken), however I did encounter a case were FDPP was also incorrect. I've attached a test binary that I ran on qemu under MS-DOS 6.22 (7.0, 7.1 were identical) to establish the correct responses. Anyway it seems that in the following cases FDPP gets it wrong.

FAIL: (sent '\dev\nul', expected '[A-Z]:/NUL', got 'C:\DEV\NUL')
FAIL: (sent '\dev\nul.ext', expected '[A-Z]:/NUL.EXT', got 'C:\DEV\NUL.EXT')
FAIL: (sent '\nul', expected '[A-Z]:\NUL', got 'C:/NUL')
FAIL: (sent '\nul.ext', expected '[A-Z]:\NUL.EXT', got 'C:/NUL.EXT')

The results are identical if the test is run on an MFS or FAT16 drive.

Note: to be sure that the redirector played no part in FDPP's results, I '#ifdefed' QualifyFilename out.

t1.zip

[stsp]

I am having entries like
this:
FAIL: (sent '\test\nul', expected '[A-Z]:\TEST\NUL', got 'C:\TESTS\TEST\NUL')
This is likely a test-case
bug. It doesn't consider
cwd.

[andrewbird]

This is what MS-DOS 6.22 does

C:\>REM - FAT16^M
^M
C:\>D:^M
^M
D:\>mkdir test^M
^M
D:\>echo hello > hello.txt^M
^M
D:\>C:\sfntruen^M
OKAY: (sent 'nul', got 'D:/NUL')^M
OKAY: (sent 'nul.ext', got 'D:/NUL.EXT')^M
OKAY: (sent '\dev\nul', got 'D:/NUL')^M
OKAY: (sent '\dev\nul.ext', got 'D:/NUL.EXT')^M
OKAY: (sent '\nul', got 'D:\NUL')^M
OKAY: (sent '\nul.ext', got 'D:\NUL.EXT')^M
OKAY: (sent '\test\nul', got 'D:\TEST\NUL')^M
OKAY: (sent '\nonexist\nul', got 'D:\NONEXIST\NUL')^M
OKAY: (sent 'C:\test\nul', got 'C:\TEST\NUL')^M
OKAY: (sent 'C:\nonexist\nul', got 'C:\NONEXIST\NUL')^M
OKAY: (sent '?:\nul', got 'ERROR: 0x0003 - malformed path or invalid drive letter')^M
OKAY: (sent 'X:\nul', got 'ERROR: 0x0003 - malformed path or invalid drive letter')^M
OKAY: (sent 'X:\test\nul', got 'ERROR: 0x0003 - malformed path or invalid drive letter')^M
OKAY: (sent 'X:\nonexist\nul', got 'ERROR: 0x0003 - malformed path or invalid drive letter')^M
PASS:^M
^M
D:\>^M

If the name is unqualified by drive, Truename has to tack on the current drive.

[andrewbird]

FAIL: (sent '\test\nul', expected '[A-Z]:\TEST\NUL', got 'C:\TESTS\TEST\NUL')

Oh, did you edit that? Why 'TESTS'

[andrewbird]

Or assuming you're testing in a directory called 'tests' then, why do you think a lookup on an absolute path should prepend the current directory to it?

[stsp]

Because, I believe,
this is not an absolute
path. \\ is an absolute
path. Not sure though. :)

[stsp]

command.com for sure
treats \ as an absolute
path, although I am not
sure about the DOS itself.

[andrewbird]

I've pushed the test branch. https://github.com/andrewbird/dosemu2/tree/ci-222 You can call it like

test/test_dosemu.py PPDOSGITTestCase.test_sfn_truename
cat test_dosemu.PPDOSGITTestCase.test_sfn_truename.xpt

However I've never considered that '\file.ext' could ever refer to anything but a file in the root.

[stsp]

Please check the PR #283

However I've never considered that '\file.ext' could ever refer to anything but a file in the root.

In this case please open
another bug, with a convincing
test-case. :)

[andrewbird]

Cool, thanks tests work fine now.

[andrewbird]

Sorry to disturb, but I found another that produces different results to current FreeDOS and MS-DOS 6.22 .. 7.10

FAIL: (sent 'C:\nul', expected 'C:\NUL', got 'C:/NUL')

[stsp]

See dosemu2/comcom64#2
And in particular this code
in djgpp:
https://github.com/jwt27/djgpp-cvs/blob/master/src/libc/posix/sys/stat/lstat.c#L497
And this comment:
https://github.com/jwt27/djgpp-cvs/blob/master/src/libc/posix/sys/stat/lstat.c#L488

         truename() which calls INT 21/AX=6000H.  For character devices
         it returns X:/DEVNAME, where ``X'' is the current drive letter
         (note the FORWARD slash!).  E.g., for CON or \dev\con it will
         return C:/CON.

[andrewbird]

I don't disagree with that statement, except that it doesn't cover the case in point. In this example the input to truename is c:\nul and the expected output is it unchanged. I know it's not official documentation, but RBIL says

under DOS 3.3 through 6.00, a device name is translated differently if
	  the device name does not have an explicit directory or the directory
	  is \DEV (relative directory DEV from the root directory works
	  correctly).  In these cases, the returned string consists of the
	  unchanged device name and extension appended to the string X:/
	  (forward slash instead of backward slash as in all other cases) where
	  X is the default or explicit drive letter.

Again it doesn't mention where the input is already fully qualified RBIL, but by omission, and the empirical data of what MS-DOS 6.22 -> 7.10 actually do would suggest the slash shouldn't be flipped.