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.