Shadow Lord wrote on 2023-02-28, 04:32:

keenerb wrote on 2023-02-27, 18:57:

There is a fork/patch to ethflop that lets you ejecte and insert disks from server side. It works very well.

I did not know of this fork. Can you please direct me to where I can find more info? Thank you!

https://forum.vcfed.org/index.php?threads/eth … os.73029/page-4

The source is available for download in a post in this forum

I've published a new version of EtherDFS today: version 0.8.3.
This version fixes a bug kindly reported by Jerome Shidel.

https://etherdfs.sourceforge.net

SvarDOS users can update it as follows:

pkgnet pull etherdfs
pkg update etherdfs.svp

Others will have to fetch the new zip file from sourceforge.

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?

ViTi95 wrote on 2023-06-28, 07:31:

One question, has been tested EtherDFS with 86Box or PCem?

I did not test any of these solutions myself, but maybe other users did. My own tests are limited to real hardware and VirtualBox.

ViTi95 wrote on 2023-06-28, 07:31:

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 relevant log is this one:

1looking for file 'doom2.wad' (FCB 'DOOM2   WAD') in '/home/viti95/fastdoom//'
2SPOPNFIL / stackattr=0040h / action=0101h / openmode=0040h / fn='/home/viti95/fastdoom//doom2.wad'
3file doesn't exist -> fail

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.

ViTi95 wrote on 2023-06-28, 22:04:

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...

ViTi95 wrote on 2023-06-28, 22:04:

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.

keenerb wrote on 2023-06-28, 22:09:

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 😀

Hello all,

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 😀

https://github.com/oerg866/ethersrv-linux-866 … 00d2d91f90afd70

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!

Thanks Oerg866!!

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?

Pierre32 wrote on 2023-08-02, 08:06:

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:

Re: RetroNAS - open source server software for your retro machines

Oerg866 wrote on 2023-08-02, 03:10:

@mateusz.viste you can use this as inspiration for how you wanna solve this issue. For now it seems to work for me :)

https://github.com/oerg866/ethersrv-linux-866 … 00d2d91f90afd70

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.

Yes, your understanding is correct.

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 😁

Oerg866 wrote on 2023-08-08, 11:25:

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.

mateusz.viste wrote on 2023-08-08, 11:58:

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.