DOS stat() pathname separator inconsistency

[dajhorn]

The DOS runtime recognizes both kinds of slashes as pathname separators, but handles them differently.

Consider this test program:

// dirstat.c
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[]) {
    if (argc != 2) {
        fprintf(stderr, "Usage: %s <path>\n", argv[0]);
        return EXIT_FAILURE;
    }

    struct stat st;
    if (stat(argv[1], &st) == 0) {
        if (S_ISDIR(st.st_mode)) {
            printf("%s is a directory.\n", argv[1]);
        } else {
            printf("%s is not a directory.\n", argv[1]);
        }
    } else {
        perror("stat");
        return EXIT_FAILURE;
    }

    return EXIT_SUCCESS;
}

Compile it with:

wpp386 -bt=dos dirstat.c
wlink system dos32a file dirstat.obj

Observed stat() behavior:

• Trailing forward-slash pathname separators are folded and stat() behaves like posix.
• Trailing backward-slash pathname separators return errno=1 (ENOENT: No such file or directory).

• Except when the pathname resolves to a drive root. (X:\ is recognized as a corner case.)

• If the stat() parameter is a file, then both slashes are folded similarly.

Expected stat() behavior:

• The DOS runtime handles both pathname separator characters similarly.
• Trailing backslashes are folded, especially in pathnames that are directories.

[jmalak]

What DOS version you are using?

[dajhorn]

This happens in:

• MS-DOS 6.22
• FreeDOS T2410
• DOSBox-X 2024.10.01

MS-DOS and FreeDOS have different / tail folding than DOSBox-X, so at least some of this stat() behavior is platform dependent.

issue1345.zip is a floppy disk image containing the dirstat.exe test program.

[jmalak]

Thanks for your bug report.
I reproduced it.
It will be corrected ASAP.

[dajhorn]

BTW, should it matter...

The __WATCOM_LFN__ macro significantly changes stat() behavior:

[jmalak]

There is issue with trailing slash.

[jmalak]

It looks like it is correct behaviour, because appropriate DOS function to access directory fails due to trailing slash.
You need to use path\last or path\last\. form.
Windows FindFirstFile has same behaviour too.
Your application is responsible to use correct format.

Anyway there was small mistake which caused strange behaviour for forward/backward slash on the end .
Now stat always report problem if there is trailing slash (forward or backward).