Fixed the error code returned when opening a file.

[nanshiki]

The error code returned when opening a file if the file did not exist was DOS_EXTERR_ACCESS_DENIED. The correct error code is DOS_EXTERR_FILE_NOT_FOUND.
The error code returned when a directory or volume label was specified when opening a file was DOS_EXTERR_FILE_NOT_FOUND. The correct error code is DOS_EXTERR_ACCESS_DENIED.

[jrohel]

The error code returned when a directory or volume label was specified when opening a file was DOS_EXTERR_FILE_NOT_FOUND. The correct error code is DOS_EXTERR_ACCESS_DENIED.

Thank you very much for the PR.

While writing code, I was thinking about which error code to return.
Example: dosemu (FreeDOS, directory "dir" exists, D: is local disk):

D:\>type dir
File not found. - `dir`

I tried running a C program. fopen returns errno == 1 and strerror(errno) returns "No such file or directory."
That's why I chose to return DOS_EXTERR_FILE_NOT_FOUND. To simulate the same behavior.

However, if I perform the same test in the Command Prompt on Windows XP:

D:\>type dir
Access is denied.

So I’m not sure which error code is more appropriate: DOS_EXTERR_FILE_NOT_FOUND or DOS_EXTERR_ACCESS_DENIED. However, I suppose that the netmount client will run on old DOS (not on Windows XP), so I prefer the old DOS behavior. The fact is, I have not tested other DOSes (MS-DOS, DR-DOS, etc.) to see how they behave (which error code they return) when trying to open a directory as a file on a local disk.
I therefore need to consider whether I want to change the error code. So far, I can’t think of a strong enough reason to do so.

[nanshiki]

When I try this on MS-DOS/PC DOS, I get
c:> type dir
Access denied - DIR
I also wrote a program that calls int 21h, but it returns DOS_EXTERR_ACCESS_DENIED=5.
I think we should follow the original MS-DOS/PC DOS behavior rather than FreeDOS.

Also, if the error code for a non-existent file is incorrect, it will actually cause problems in the application and need to be fixed.
The return value of drive.get_server_path_dos_properties is 0xff when the file doesn't exist, causing (attr&FAT_RO) to be true.
In the case of EXTENDED_OPEN_CREATE_FILE, it is being processed correctly, so I believe this is a bug.

[nanshiki]

In FreeDOS 1.4, I opened a directory with int 21h ah=3dh and checked the error code, which was 5.
I think the reason why type dir returns "File not found" is a bug in FreeDOS's command.com.

[1ras]

I just tried it with DR-DOS 7.03 since I have it available. On a native system, it returns:

C:>type drdos
Access denied

But in Dosemu2 it returns:

C:>type drdos
File not found

But when booting Dosemu2 from a floppy or hard drive image instead of an emulated file system, then it returns:

C:>type drdos
Access denied

There might be an issue with the emulated file system of Dosemu.

(drdos is the DR-DOS installation directory, of course it exists on all installations)

[jrohel]

@nanshiki
Thank you very much for the tests.
I agree with the change to DOS_EXTERR_ACCESS_DENIED. I can make the fix myself, or you can rebase your PR.

To keep the code formatting consistent, I use clang-format. Some time ago I added the ".clang-format" configuration file used by the project to the repository, and today I added GitHub workflows so that formatting checks run automatically (on push and on new PRs — your PRs were created earlier, so the workflow configuration will only be taken into account after they are closed and reopened). The workflows also run test builds of the code. However, this may not be fully working yet for external PRs.

Since the project consists of multiple parts, I use the server: prefix for commits that affect only the server.
For example:
server: fix: return DOS_EXTERR_ACCESS_DENIED when opening dir as file

[nanshiki]

You fix it.

[jrohel]

@nanshiki

You fix it.

Thank you for the PR and the tests. I’ve started extending netmount-server with support for read-only sharing. While doing so, I’m touching the code in areas that this PR also modifies, so I’ll include this fix as well.

Note: I still need to determine which error should be returned when a write is attempted while the disk is shared read-only - DOS_EXTERR_ACCESS_DENIED or DOS_EXTERR_DISK_WRITE_PROTECTED. Logically, I would expect DOS_EXTERR_DISK_WRITE_PROTECTED, but this will need to be tested to confirm the behavior.

[1ras]

Maybe it's helpful how a write-protected floppy disk and CD-ROM behaves on a native DR-DOS 7.03 system:

Floppy disk:

C:\> echo bla > a:\bla.txt

Write protect error writing drive A
Abort, Retry, Fail ?

C:\> del a:\config.sys

Write protect error writing drive A
Abort, Retry, Fail ?

CD-ROM with NWCDEX 2.81:

C:\> echo bla > o:\bla.txt
Disk write-protected

C:\> del o:\readme.txt
File not erased: o:\README.TXT - Disk write-protected

Unfortunately, the same CD-ROM with SHSUCDX 3.09 behaves differently:

C:\> echo bla > o:\bla.txt
Invalid directory specified

C:\> del o:\readme.txt
File not erased: o:\README.TXT - Invalid directory specified

[jrohel]

I created a test program that calls DOS file services (INT 21h) and prints the results. I am testing various scenarios on the local filesystem and on the NetMount drive under different DOS versions. Based on the results, I am preparing fixes and adjustments. Therefore, the next version of NetMount will include multiple changes.