Definitely! Are there any difficulties on the server side getting it up and running?

No server-side problems at all. I used a VMWare VM as the linux server, but I'll be switching to a Raspberry PI tonight

I downloaded the server source file, unzipped it, entered the directory and ran "make". In about a tenth of a second it returned to the command prompt, I thought compile had failed, but there was a new executable.

I ran "./ethersrv eth0 /mnt/dosroot" on the server as root, it forked to background.

On my Tandy I ran "lh etherdfs :: c-f /p=60" and F: was mapped to /mnt/dosroot. I played a half-hour of Telengard with no problems, and followed it up with a good hour of Champions of Krynn.

I will also share the folder out via CIFS and I can map the same folder to a windows machine to use with Dosbox, which will be pretty neat. D:\ on my Dosbox installs will be D:\ on my Tandy as well, as long as I'm careful to avoid file sharing issues.

I did get a complaint about not using an MSDOS file system on the server-side (I think), so I'm going to switch to a vfat formatted partition on an sd/cf card so that "." and ".." directory entries don't cause any problems.

Seems this solution is not quite 100%.

I'm unable to run certain programs from the mapped drive; can't identify why.

Telengard runs fine, Dungeon Master complains it needs the MASTER disk. Geoworks 2.0 doesn't recognize SETUP.EXE as a valid command, says file not found...

Hmmm. So it presents a funky view to DOS, which is kinda a risk with IFS stuff.

Still a pretty good solution for copying stuff from a more modern box, though. But, note made - install from etherdfs, don't plan on running from it. Ah well, CF cards are cheapish.

I think it's related to one of his recent commits. I'm going to roll back to an earlier build, and send him a message.

I was wrong; vfat default to UTF-8 codepage and actually uses case sensitivity. I could see on the server where the ethersrv-linux was complaining that "/mnt/dosdisk//geos20" didn't exist, it was "GEOS20" and case sensitivity was breaking it.

Changing "mount -t vfat" to "mount -t msdos" seems to have fixed it, although my testing time this morning was limited.

Oh, right, because vfat uses the same case-preserving and semi-sensitive thing that WinNT does on NTFS (or at least used to do, inherited from what OS/2 did on HPFS). Causes some weirdness; I vaguely remember some funky edge cases popped up win the Win95 days if you tried to run a Win32 app that knew about NT3/NT3.5's filename handling (cases where you could save a file with an LFN and then open it, but sometimes other files had to be opened by their bogoname and the LFN didn't work.)

Good catch there too.

Wasn't me, it was the dev. I got in touch with him on sourceforge.

Basically, mount your msdos partition with "-t vfat -o iocharset=cp437" (or other appropriate code page) in which case you'll still SEE case sensitivity, but <FILENAME> operates the same as <filename>.

Or mount with -t msdos, in which case everything appears lowercase.

"-t vfat" is what breaks everything.

Sounds like it needs some server-side code to avoid case sensitivity, like Samba does when sharing a case-sensitive filesystem over CIFS.

I don't like the idea of having a special filesystem just for DOS stuff on the server so I may delve into the code if this is still a problem when I get the time to set this up.

Not sure how Dungeon Master checks its disks but I'm guessing it's looking at the volume label and these don't come across, or it's trying to read direct disk sectors which is not possible with any sort of network drive.

dungeon master was an incomplete install it's working fine now.

I don't think it'll be quite that easy to solve the case sensitivity issue, considering the DOS side is insensitive.

If I have two folders "APPS" and "Apps", in a folder mapped to a DOS client which becomes D:\APPS?

In Samba, one of them becomes D:\APPS and the other becomes something like D:\APPS~1. I'm not sure if there are any rules (like the capitalised one always comes first) or if it just depends on the order of the directory listing. But at the end of the day, how many people are going to have multiple folders that only differ by case in with their DOS stuff? I never have folders that only differ by case with my *Linux* stuff, let alone DOS! Personally I don't think it's a scenario that will have to be handled very often, if at all.

Malvineous wrote:

Sounds like it needs some server-side code to avoid case sensitivity, like Samba does when sharing a case-sensitive filesystem over CIFS.

As keenerb observed, "easier said than done" :-) As soon as case-sensivity is involved, lots of ugly corner cases appear. Dealing with them rapidly becomes a nightmare, that's why I simply recommend using a 'msdos' mounted fs.

I don't like the idea of having a special filesystem just for DOS stuff on the server

Well, if you only use the volume through etherdfs (ie. you don't write anything to it from within Linux), you will be fine. ethersrv makes sure to always use the same case.

It's also worth noting that you don't need to dedicate an actual partition - you may just as well mount a fat image through loop.

What are some of the corner cases that come up when you're only dealing with converting an ASCII character set to upper/lower case?

I will point out that you can actually have lowercase characters (and spaces) in native DOS filenames on-disk, however it causes many problems as programs typically can't access them - everything is designed for uppercase-only filenames. So you need to convert all your filenames to uppercase anyway, no matter what the host filesystem is.

Malvineous wrote:

What are some of the corner cases that come up when you're only dealing with converting an ASCII character set to upper/lower case?

File matching. An application wants to open 'FILE.TXT', and on disk there is 'file.txt', 'FILE.txt' and 'FILE.TXT'. Which one do I actually return?
Later, an application wants to delete FILE.TXT. Same problem.
What about FindFirst/FindNext? Do I list all the files, even though most of them are inaccessible?

Any attempt to handling this will lead to a mess that I simply don't want to deal with (and with the user bug reports that it would lead to).

Like I said above, you do it the way Samba does. First file is FILE.TXT, second is FILE~1.TXT, third is FILE~2.TXT, etc. That problem has already been solved. Heck even DOSBox does it this way, but most people don't even notice because you never have files named like this anyway unless something has gone wrong.

DOSBox is open source, if it bothers you writing the code to handle names like this, just copy it from DOSBox.

Malvineous wrote:

Like I said above, you do it the way Samba does. First file is FILE.TXT, second is FILE~1.TXT, third is FILE~2.TXT, etc. That problem has already been solved. Heck even DOSBox does it this way, but most people don't even notice because you never have files named like this anyway unless something has gone wrong.

DOSBox is open source, if it bothers you writing the code to handle names like this, just copy it from DOSBox.

As I said already, I won't waste my time with this mess. That being said, EtherDFS is an open-source project. Patches welcome!