Some new findings!

When using a FAT32 drive on my Linux VM, the slow speed issues are resolved. Also using a better benchmark utility now. The results:

Creation of 100MB file
NDIS2/Samba -> 5.58 MB/sec
Packet/EtherDFS -> 3.04 MB/sec

Regarding to the "File not found" issue: using a FAT32 drive does not resolve my issue with copying newly created files. However, it seems to be related to the shell I'm using (4DOS):

- After file creation, I can only use type/head to view the file, but not copy it back again - "File not found"
- If at that time I start a COMMAND shell (on top of 4DOS), I can copy the new files created in 4DOS shell just fine
- exiting COMMAND and returning to 4DOS shell and I get a "File not found" error again on the same file

Weird thing is: a file created in 4DOS, is only -viewable- in 4DOS and _not_ in COMMAND (using type, contents are empty) - but copy works only in COMMAND, after which I can view the contents of this file on my local disk successfully

Hope this makes sense 😀

EDIT: Also just lost the connection to EtherSRV again (to FAT32 drive) - drive listing empty. But no errors on server side.

Thanks for your feedback! So you use 4DOS, that's good to know -- I suppose it does something differently than command.com. So far I tested EtherDFS only on FreeDOS and MS-DOS 5.x and 6.x, while you seem to be running the Windows 95 shell. I will try to setup some lab with the Win95 shell and see what's going on.

I assume you tested it all using latest version of EtherDFS (0.7) and latest ethersrv (20170211), right?

mateusz.viste wrote:

Thanks for your feedback! So you use 4DOS, that's good to know -- I suppose it does something differently than command.com. So far I tested EtherDFS only on FreeDOS and MS-DOS 5.x and 6.x, while you seem to be running the Windows 95 shell. I will try to setup some lab with the Win95 shell and see what's going on.

I assume you tested it all using latest version of EtherDFS (0.7) and latest ethersrv (20170211), right?

I'm using 4DOS 8.00 as a replacement shell for COMMAND.COM on MS-DOS 7.10. Sorry, should have mentioned that earlier. It is not related to Win95 however. You can grab the open source version here: https://www.4dos.info/4dvers/4dos800.zip - "Free 4DOS", more info here: https://www.4dos.info/v4dos.htm#751

Yes, using EtherDFS 0.7, and ethersrv (20170211).

Hello all! Today I published a new, improved version of EtherDFS (along with its companion Linux server - ethersrv-linux). Download available, as usual, on the project's website: http://etherdfs.sourceforge.net

v0.8 [2017-03-04]: - improved self-detection to avoid loading EtherDFS twice, - added unloading support (/u), - fixed a FindF […]
Show full quote

v0.8 [2017-03-04]:
- improved self-detection to avoid loading EtherDFS twice,
- added unloading support (/u),
- fixed a FindFirst regression (fixes usage under 4DOS),
- fixed SETATTR action when using a non-FreeDOS attrib command,
- implemented the 'Seek From End' call,
- minor memory optimizations,
- makes sure the redirector API is available before installing,
- support for multiple drive mappings.

Great news! A lot of improvements, as it seems from the change logs on both EtherDFS and ethersrv. Your work is much appreciated! Especially the unload option is very welcome for me (as you know). I will be trying this new version soon, and report back the results here 😀

Finally found some time to perform some tests with this new version.

The new version works good under 4DOS now!! 😎 Thanks for the fix! No issues with creating/viewing/removing files. Unloading works like a charm (and unloading the packet driver afterwards as well)
The only small issue I ran into:
- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once - I have to run this command multiple times in a row. ethersrv throws errors: RMDIR Error: Directory not empty, which of course is correct. The same test with "DELTREE /Y *.*" on the same dataset on a local drive does remove all data in one go.

Furthermore: what about LFN support? (using DOSLFN ie) Is this on your wish list? Right now when I copy files from Linux to my FAT32 drive with some or all capitals or files that do not meet the 8.3 character criteria, ethersrv shows: ERROR: invalid handle, when trying to access the files from MS-DOS (which shows "Access denied" by itself). I have to first remove the capitals and convert the filename to 8.3. I understand that is currently not possible to create LFN files from EtherDFS, but perhaps it is possible to allow EtherDFS to access LFN files? (by stripping/ignoring LFN values on access, just like MS-DOS does when Windows is not loaded)

Tiny request: allow combining /U and /Q parameters. Can easily be worked around by using "ETHERDFS.EXE /U>NUL", but oh, well 😊

All in all this version works great. Awesome work, mateusz.

mOBSCENE wrote:

The new version works good under 4DOS now!! 8) Thanks for the fix! No issues with creating/viewing/removing files. Unloading works like a charm (and unloading the packet driver afterwards as well)

Sounds great! I'm glad it works for you.

mOBSCENE wrote:

The only small issue I ran into:
- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once

I am aware of this. In fact, this is something I already fixed a week ago, but had no time to release it formally yet (and got temporarily distracted by another retro project). If you feel courageous, you might try upgrading to latest SVN version of ethersrv (no EtherDFS change is necessary). Latest SVN version of ethersrv is here:
https://sourceforge.net/p/etherdfs/code/HEAD/ … rv-linux/trunk/ (click on "download snapshot").

mOBSCENE wrote:

Furthermore: what about LFN support? (using DOSLFN ie) Is this on your wish list?

Not really in my plans, since I do not use it myself.

mOBSCENE wrote:

Right now when I copy files from Linux to my FAT32 drive with some or all capitals or files that do not meet the 8.3 character criteria, ethersrv shows: ERROR: invalid handle, when trying to access the files from MS-DOS (which shows "Access denied" by itself).

Just a hunch: isn't this because your Linux is (wrongly) treating the file system as case-sensistive? I think there are some options that need to be passed to mount, like "iocharset" or "charset", not sure which (myself I use the "msdos" mount filesystem which works properly out of the box, but I know that vfat is trickier). Last time I tried to mount a fat drive using the vfat driver I remember Linux shouting at me "warning, this filesystem will be case-sensitive" (not exact words), this appeared in the dmesg.

mOBSCENE wrote:

I understand that is currently not possible to create LFN files from EtherDFS, but perhaps it is possible to allow EtherDFS to access LFN files? (by stripping/ignoring LFN values on access, just like MS-DOS does when Windows is not loaded)

Yes, this is definitely something that needs to be addressed. Well, the "case sensitivity" issue is, I believe, a problem of your mount configuration, but "long filename to short filename" is a feature that ethersrv would need to perform on its own. I will think about how to address that.

mOBSCENE wrote:

- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once - I have to run this command multiple times in a row.

Hello, yesterday I released a new version of ethersrv-linux that fixes tha above issue.

Hi @mateusz.viste and thanks for this great tool. I'm having a problem which I don't think is the fault of EtherDFS, but maybe I can get some insight here.

My server is a Raspberry Pi with a fresh install of Raspberry Pi OS Lite. Client is DOS 6.22. On the testbench, with the machines connected through a little 5 port hub, everything works perfectly:

[Pi server]---cat6---[hub]---cat6---[DOS client]

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It works well for TCP/IP stuff. Ideally I want my Pi in another location, also accessible by wifi. This is the setup:

[Pi server]---cat6---[Ubiquiti Amplifi router]---wifi---[TP Link nano router]---cat6---[DOS client]

When I run etherdfs on the client, it appears to find the server MAC and start up. I can navigate to my mapped drive, but can't get a directory listing (File not found).

I don't really have any understanding of network protocols. Is it possible that one or both of my wifi routers are rejecting the traffic?

Pierre32 wrote on 2021-01-15, 22:22:

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It work […]
Show full quote

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It works well for TCP/IP stuff. Ideally I want my Pi in another location, also accessible by wifi. This is the setup:

[Pi server]---cat6---[Ubiquiti Amplifi router]---wifi---[TP Link nano router]---cat6---[DOS client]

When I run etherdfs on the client, it appears to find the server MAC and start up. I can navigate to my mapped drive, but can't get a directory listing (File not found).

I don't really have any understanding of network protocols. Is it possible that one or both of my wifi routers are rejecting the traffic?

If by "router" you mean "something that actually performs IP routing", then EtherDFS won't work, as it requires the client and server to be on a common Ethernet segment. If, however, "router" is your term for a wifi AccessPoint, then it can work - assuming the accesspoint is in some bridge-like mode and does not try to apply any kind of firewalling of its own. That being said, I have seen wifi APs that, although configured as a supposedly "transparent" bridge, were still allowing only IP traffic to pass, EDF5 frames were dropped (this was the case, IIRC, with my TP-Link RE350 AP). It is possible you have hardware that misbehaves in a similar way - in such case, all you could do is try fiddling with AP's settings to figure out how to make it a true bridge. Or use another AP.

Perfect answer, thank you. Sounds like I may be right to suspect the TP Link, so I'll explore options there. It also wouldn't be the end of the world just to move my Pi to where the retro gear is.

That's a really useful tool! Any chance of getting a Docker package? I'd like to use it on my NAS.