fcb rename wildcard expansion
andrewbird opened this issue · 4 comments
I've just been testing FreeDOS current git with the Dosemu2 test suite and I can see that there's a problem with FCB rename when using wildcards. The test test_fat_fcb_rename_wild_1 and three others are failing due to a bug still present in FreeDOS, as I reported a similar one in FDPP here dosemu2/fdpp#44 which was subsequently fixed. That bug report contains a test binary that should help you to recreate.
now passes the 4 fcb rename test cases
Thanks, that fixes it on the Dosemu2 test suite too. The only failing tests remaining are those that can be attributed to 'share'. I'm currently using the 'share.com' that came with FreeDOS 1.2 and obviously I should be using the latest and greatest, however I see that 'share' is both part of the kernel repo and also a standalone repo https://github.com/FDOS/share. I notice that the Makefile speaks of building with TC 2.01 and in share.c it will error out if not, so is building with gcc and Watcom not possible?
Currently share.c does require TC 2.01; it might build with TC++ 1, but did not build with version 3 for me. I have moved (the source is the same right now) it to its own repository so it can be updated/modified independently of the kernel, however, I plan to make it a submodule of the kernel so it continues to be built and included with the kernel. [I haven't used submodules with git yet, so something new to learn which is why I haven't done it yet.] I am working on adding (and fixing) tests to the kernel now. I will look for it, but it you have a handy pointer to the failing test I will look into it.
Firstly we decided to make share a part of FDPP and is always enabled, and so far hasn't caused us any problems. When doing this I decided to test all the combinations in the matrix documented on RBIL against MS-DOS 6.22 which was correct but with our internal share and the FreeDOS 1.2 one I found differences. Some may be intentional changes to be more like the Win95 implementation, which may be what FreeDOS people want? In our case it was thought to be more desirable to be compatible with one version. Here is the test func_ds3_share_open_twice which aims to open a file with a certain share and access mode, then spawn another copy of itself that requests perhaps different modes and record the result. It's compiled with DJGPP but probably would be okay with gcc-ia16-elf, which might be even better if you want to detect the difference between a plain failure and one that causes Int24 as it's quite easy to write an interrupt handler with it now.
I just ran the test again against FreeDOS 1.2's share and there are 10 failures out of 225 subtests. Unfortunately to run standalone the test logic for matrix interpolation is in the python so you'd need to recreate that in a batch file I guess. But for reference, should you decide there is something to fix, the failures are here:
Test FR-DOS-GIT FAT DOSv3 share open twice ... FAIL (one or more subtests)
(t=('SH_COMPAT', 'R', 'SH_DENYWR', 'R', 'DENY')) ... FAIL
(t=('SH_COMPAT', 'R', 'SH_DENYNO', 'R', 'DENY')) ... FAIL
(t=('SH_DENYWR', 'R', 'SH_COMPAT', 'R', 'INT24')) ... FAIL
(t=('SH_DENYWR', 'W', 'SH_DENYRD', 'R', 'ALLOW')) ... FAIL
(t=('SH_DENYWR', 'W', 'SH_DENYNO', 'R', 'ALLOW')) ... FAIL
(t=('SH_DENYWR', 'RW', 'SH_DENYNO', 'R', 'ALLOW')) ... FAIL
(t=('SH_DENYRD', 'W', 'SH_DENYRD', 'W', 'ALLOW')) ... FAIL
(t=('SH_DENYNO', 'R', 'SH_COMPAT', 'R', 'INT24')) ... FAIL
(t=('SH_DENYNO', 'R', 'SH_COMPAT', 'W', 'INT24')) ... FAIL
(t=('SH_DENYNO', 'R', 'SH_COMPAT', 'RW', 'INT24')) ... FAIL
To look at one line in detail
(t=('SH_DENYNO', 'R', 'SH_COMPAT', 'RW', 'INT24')) ... FAIL
The primary copy of the test opens a file with share mode deny none and file mode readonly
The secondary copy opens the same file with share mode compat and file mode readwrite
It's expected by RBIL (and MS-DOS 6.22 confirms) that this should result in a fail via Int24
But that didn't happen (it probably was allowed, but there's more test output detail in the python backtrace, not posted here)
Regarding your test suite, once you get it hooked up to Github Actions you'll find it very useful as it gets run on each push or PR request. Of course that's dependant upon having lots of tests, which is a considerable work in its own right.