One question, has been tested EtherDFS with 86Box or PCem? I want to get rid of DosBox for develop as it's x86 emulation is inacurate, and I was thinking of using EtherDFS as a fast way to execute code on the emulator. Also, is it possible to modify the files on the server in realtime and will those changes appear on the mapped drive?
is it possible to modify the files on the server in realtime and will those changes appear on the mapped drive?
Yes, although care must be taken not to modify files that are already open by a DOS application, as said application could get very confused if the file's content suddenly changes.
I've been able to make 86Box to work with EtherDFS on my Windows based machine, but there are some issues. Basically I have a Debian WSL2 instance running on my Windows 10 laptop where I develop FastDoom.
I've setup EtherDFS server to host my builds folder on the virtual WSL2 machine. 86Box runs on the Windows side, and I've setup a network connection via ISA NE2000 device that connects directly to the WSL2 virtual network via PCap. Both machines are able to communicate but then some issues while copying/executing files appear:
This is the configuration and the network device used:
Maybe I'm missing something. I've also tried to use it on a real 486 with an Ethernet-to-WiFi adapter but didn't work (that was pretty much expected), will try again on that system when I get a crossover ethernet cable.
EDIT: I've also attached two WireShark captures from the virtual network device
EDIT2: I've attached the log EtherDFS-srv produces (found the DEBUG variable):
The "file doesn't exist" message is somewhat misleading, because the file does appear earlier in your listings. Looking at the code it would seem that a stat() call on the file succeeds, but opening it fails.
I do not know anything about the WSL thing, but is it possible that the ethersrv process has insufficient access rights to read the files? You might want to, perhaps, try out running ethersrv on a VirtualBox VM to see if things are any different.
An alternative theory could be that for some reason the two slashes in the path are confusing WSL, but that would be really odd.
I've also tried to use it on a real 486 with an Ethernet-to-WiFi adapter but didn't work
Wifi adapters tend to be picky about non-IP and non-ARP traffic.
I've found the issue, there is a problem while reading files that are uppercase in the server file system. For example, if the original filename is "FDOOM.EXE" it fails reading it, but if the filename is "fdoom.exe" then it works perfectly fine. I'll try to patch it.
BTW, the WSL thing is just a virtualization of Linux that integrates with Windows. For me there is no difference between developing directly on Linux or using a WSL distro.
I've found the issue, there is a problem while reading files that are uppercase in the server file system. For example, if the original filename is "FDOOM.EXE" it fails reading it, but if the filename is "fdoom.exe" then it works perfectly fine. I'll try to patch it.
BTW, the WSL thing is just a virtualization of Linux that integrates with Windows. For me there is no difference between developing directly on Linux or using a WSL distro.
This is also an issue with normal linux systems. I ended up formatting a disk image as VFAT/MSDOS and mounting it as a loopback device, it avoids the case sensitivity issue...
I've found the issue, there is a problem while reading files that are uppercase in the server file system. For example, if the original filename is "FDOOM.EXE" it fails reading it, but if the filename is "fdoom.exe" then it works perfectly fine.
Good to know you figured it out. It's actually one of the reasons why I recommend using FAT as the etherdfs storage. Avoids such headaches. The other reason is FAT attributes.
I'll try to patch it.
Patches are always welcome. The fix is not as trivial as it might seem, though. Needs lots of testing, esp. for cases where several variants of a file exists (File.txt, FILE.TXT, file.txt, FiLe.TxT, ...) - to make sure for example that EtherDFS won't read from one file but write to another. Or that it will create a new file even though another file with the same name but different case exists already.
This is also an issue with normal linux systems. I ended up formatting a disk image as VFAT/MSDOS and mounting it as a loopback device, it avoids the case sensitivity issue...
Some Linux filesystems, like ext4, do support case insensitivity. There is a guide to enable the feature, basically it's a 2-step process, enabling it on the filesystem, then on individual directories.
I haven't tried it though, I actually patched EtherSRV to use uppercase-only filenames and to ensure the exported directories have uppercase filenames so they maintain the "DOS look" even when browsing through them on Linux 😀
I hacked together a quick solution for filesystem case sensitivity as well as being able to access longer filenames through their truncated names (and also make it skip spaces in the file/dir names).
@mateusz.viste you can use this as inspiration for how you wanna solve this issue. For now it seems to work for me 😀
Oh!! I'll try this as soon as possible! I was testing stuff on 86Box and DosBox-X using the Hercules InColor video card and found a pretty bad bug on DosBox-X, so I had to rely on 86Box to continue developing and testing. This will speedup things a lot!
Nice work. Can you explain like I'm five how it operates? Is it making renamed copies of the files, or effectively doing some aliasing?
I think the clues is in readme
>While longer file names and files with different capitalization can be
accessed in this fork, it will only pick the first file it finds that matches
to acces, meaning that in case of naming conflicts you may end up accessing
the wrong file or directory
Yes, that's correct. It's definitely not an ideal scenario, a more "useful" approach would be to traverse every new directory and make proper names with "~n" suffixes. But that is too complex for a simple patch, I think.
Again, nice work. I'll be keen to try out your fork some time.
I approached this issue a while back, and in keeping with my skill set (adapting the work of smarter people) I went down the path of a bash script to create a dedicated, renamed copy of my files, truncated and incremented. It has its own drawbacks, but it's useful for taking a static file collection and making it DOS / EtherDFS friendly. Links to script & commentary here:
If I understand this correctly, in case of two "same" files being present in a directory on the server:
FILE.txt
FILE.TXT
Only one of the files will be listed on the DOS side. Then, issuing a "DEL file.txt" will delete one of the file, and start exposing the other. Same for directories. Is that right? Sounds like an open door for lots of dangerous scenarios.
But I think I prefer access to my files without having to force myself to write every file name in lower-case. Because as it is, with the stock etherdfs i wasn't able to access *anything* on my NAS and renaming all the files and stripping the spaces simply wasn't an option for me 😁
Plus, these scenarios are very rare to begin with in a retro software library if you think about it.
Also, this code is definitely a basis for a complete solution to this problem. It can be expanded with a proper 8.3 generator. Maybe store a database in the root folder (or memory, chances are we've got plenty). But I'm not smart enough to implement this so I'll be content with this for now 😁
But I think I prefer access to my files without having to force myself to write every file name in lower-case. Because as it is, with the stock etherdfs i wasn't able to access *anything* on my NAS and renaming all the files and stripping the spaces simply wasn't an option for me :D
I understand the need and I respect the work you have put into your solution, I'm just pointing out it is not without extra risks and might lead to very weird border effects. I wonder if such logic wouldn't be safer, while still staying relatively simple:
For any filename, look for all its upper/lower combinations and longer versions. For instance for a filename "diskcopy.asm" check for the presence of:
diskcopy.asm*
DISKcopy.ASM*
DiskCopy.asm*
diskcopy.asm*
etc
If one match is found - use it (or report in DIR listing). if two or more matches are found - ignore them both, ie. the file becomes invisible. And if DOS tries to OPEN such file, then return an "access denied" error. It's still an ugly contraption, but maybe less bad than blindly matching filenames for all operations.
Might also be interesting to look at how other projects solve this issue (DOSBOX, DOSEmu...) since they are obviously confronted with the same problem.
Might also be interesting to look at how other projects solve this issue (DOSBOX, DOSEmu...) since they are obviously confronted with the same problem.
The project that put most likely most energy into this issue is samba.