Nice writeup!

I did a bit of testing last night to see how Mars NWE handled this situation. I suspect its a bug as the behaviour is different from what real NetWare does but Mars NWE seems to just hide files with long filenames from DOS. If you have two files, "long_file_name" and "long_file_name_too" Windows 9x/NT (and I expect OS/2) clients will see both but DOS clients will see neither. I guess its better than an error but I think I prefer mangled filenames like Windows and real NetWare do - then files with long names are at least accessible if you really need to.

Cheers 😀

When I was discussing this on OCAU, Grant shared another tip on the topic. If you mount your shared volume to the Pi as 'msdos' instead of 'vfat', it will truncate the filenames in the classic way that we're used to. But apparently you need to be careful copying data onto this volume, as similar long filenames can overwrite each other. I haven't experimented beyond vfat yet.

On a similar track, I've scraped together a bash script that permanently truncates files which is useful for certain collections. I'll definitely be writing about this one too.

Pierre32 wrote on 2022-03-10, 02:09:

Cheers 😀

When I was discussing this on OCAU, Grant shared another tip on the topic. If you mount your shared volume to the Pi as 'msdos' instead of 'vfat', it will truncate the filenames in the classic way that we're used to. But apparently you need to be careful copying data onto this volume, as similar long filenames can overwrite each other. I haven't experimented beyond vfat yet.

On a similar track, I've scraped together a bash script that permanently truncates files which is useful for certain collections. I'll definitely be writing about this one too.

Would be cool if it could do a dry run first to show what its found and what it will rename it to - its a pain doing it by hand!

One thing I discovered last night while having a closer look at EtherDFS was the PLIP packet driver. I was wondering if it would be possible to get some older laptops like the T1000 (if it still works) on the LAN but those Xircom parallel port ethernet adapters are just way too expensive. PLIP looks like a good alternative - I wonder if the various hardware solutions sold for Amigas (plipbox) use the same protocol as the DOS packet driver or if it really has to be a DOS or Linux machine at the other end of the Laplink cable.

DOS packet driver uses 4 bit PLIP... Amiga PLIP was variously supported as 8 bit for betwixt Amigas only or the PC/Linux 4 bit version for interoperability, BUT I don't know which the plipbox uses, so it's a fiddy fiddy shot.

edit: BTW... Win 9x thru 7 will share TCP/IP through a PLIP connection with a parallel laplink (4 bit) cable, super easy to set up with "Internet Connection Sharing" .. of course you need a parallel port on the box you're connecting to.

Out of curiosity, has anyone tested RetroNAS on other hardware, or a Turing Pi? I wonder about the performance differences.

daibido1123 wrote on 2022-03-26, 00:50:

Out of curiosity, has anyone tested RetroNAS on other hardware, or a Turing Pi? I wonder about the performance differences.

We've got loads of users running this on low end x86 hardware as well as VMs. Performance is relative to your server hardware as much as your client - things like PlayStation2, Xbox360, MS-DOS, etc all tend to run on 10/100 Ethernet, and even then rarely get close to line speed on the client side, so it doesn't tax an RPi4 let alone an x86 box.

Once people push into PlayStation 3 or Windows 2000 and newer type devices with Gigabit hardware, then things get interesting. RPi3 hardware can't do that, but RPi4 with a big fat USB3 drive can happily saturate 1000Mbps, and depending on bus speeds and NICs can even occasionally be faster than local IDE HDDs.

Where people appreciate the speed is when they plug huge drives into RetroNAS and then fill them up over the network from their modern PCs. But again, once you connect up via your older systems, the bottleneck is almost always the older client and network hardware than even an RPi4 with it's 1.5GHz quad core CPU, 2GB+ RAM, 1Gbps NIC and 5Gbps USB3 connections (a relative monster compared to some of the old computers I have lying around).

Hi Pierre32 - in your blog posts you mention working to get EtherDFS setup, then noted a problem while copying a bunch of files from GoG (the transfer stopped). Your solution was to use ProFTPd to complete the transfer.

I'm wondering if setting up EtherDFS is worthwhile, especially if it's not reliable. How has your experience been since then, do you continue to use EtherDFS or do you revert to FTP for large transfers?

I don't think EtherDFS is necessarily unreliable, just that it doesn't support long filenames. As long as all the files on your network volume have 8.3 filenames you shouldn't have any trouble. Network products designed for DOS (like the FTP client Pierre32 is using, or other network drive solutions from Novell/Microsoft/Banyan/Sun/etc) usually automatically converted filenames to 8.3 as necessary but it sounds like EtherDFS doesn't have that feature - instead it just refuses to work with files that have invalid DOS filenames.

You'd probably find network drives much more convenient than FTP - you don't even have to copy stuff to your local disk, you can run games/installers/etc straight from the LAN. I certainly wouldn't want to rely on FTP alone - not if I had another choice. And for network drives on DOS EtherDFS is the easiest option that won't consume huge amounts of conventional memory. The only other thing that will work with RetroNAS right now is the Microsoft SMB client but that will use (IIRC) around 170KB of conventional memory which is too much to just leave running all the time. The Novell client uses only a maximum of 4KB of conventional memory including NIC driver on a 386+ (on a 286 around 50-60K if you can't load high, 8086 around 60-80K) but RetroNAS doesn't currently support this making it the most difficult of the DOS network drive options - you'd have to setup the server end yourself on a linux box or in a VM.

So with the 8.3 format is that like 12 characters in all.. 8 plus period plus 3?

Kind of. Records in a FAT directory table contains separate fields for filename (8 characters, padded with spaces) and extension (3 characters, padded with spaces, optional). If an extension is present then DOS will automatically add the period on display (and expect you to supply it when you enter filenames). Subdirectories are stored in the same table (they're just regular directory entries with the 5th attribute bit set) and so are subject to the same limitations.

I think EtherDFS is probably the killer networking tool for DOS. It's the one I use 99% of the time for transfers, as you just can't beat a mapped network drive.

Its intolerance of long filenames is a minor annoyance, so I just set out to detail a workaround. But my intention wasn't to paint EtherDFS in a bad light 😀 In truth it's pretty rare that I'll be transferring GOG's DOS games directly to a real DOS system, as they tend to present so many challenges (not just their added files, but they're often missing original setup files too). For my main DOS library on the NAS I tend to source "clean and complete" versions elsewhere, and for transferring those, EtherDFS is pretty bulletproof.

Probably nothing can be a bigger screwup though than when I had a Linux machine, Win95, Amiga OS 3.0 and DOS 6.22 with some extender all writing to one volume hosted on 95.... I don't recall exactly what happened as this was a quarter century+ ago but it seemed like it was either early and buggy linux FAT32 support or the DOS 6.22 LFN kluge that did the most damage... I believe the way I had the Amiga patched in it translated to native both ends, so it was really Win95 handling it... anyhoo, before long the filenames were all random scrambled chars and somehow I got 20 GB of free space on a 1GB partition. They only had access one at a time too, wasn't some lack of file locking.

If you haven't inadvertently forced a File Allocation Table to stick it's head up it's own arse* at least once in your life, then you aren't a true nerd (nerd nerd ..). Or at least, you're a far more cautious one than I.

*by way of some sort of capacity/wrap-around corruption

Impressive!

Another filename challenge I've had is with running emuators in DOS. For this I opted to shorten ROM filenames before transferring. I scraped together a bash script (actual writing credit goes to Google and Stack Exchange) that does some pretty brutal truncating, so I don't have to worry about their insane filenames tripping up EtherDFS or the emulators. Details here if anyone's curious:

https://forums.overclockers.com.au/posts/19094914/
https://forums.overclockers.com.au/posts/19095115/

IPX is still on my to-do list for RetroNAS. But I've got some nagging networking stuff I want to get out the door first - a basic LAN segmenter with firewall and DHCP server, and some PPP over serial stuff.

elvis wrote on 2022-04-15, 08:05:

IPX is still on my to-do list for RetroNAS. But I've got some nagging networking stuff I want to get out the door first - a basic LAN segmenter with firewall and DHCP server, and some PPP over serial stuff.

I pulled Mars NWE into github a few months back so it doesn't get lost and added tidied up build and setup instructions which might be useful when you get to it.

davidrg wrote on 2022-04-15, 09:09:

I pulled Mars NWE into github a few months back so it doesn't get lost and added tidied up build and setup instructions which might be useful when you get to it.

Brilliant, thank you. That's mighty useful.

Big guide up today on some of the magic you can do with sparse files, loopback mounts and the "fstrim" command in Linux to present up to 16TB of space to a real MS-DOS machine via EtherDFS:
https://github.com/danmons/retronas/wiki/FAT

Thanks to sparse files and trim, only the space used by data within the image is actually used on disk (and that too can be compressed with BtrFS lzo/zstd compression below it).

If anyone uses this, let me know your experiences.

elvis wrote on 2022-04-15, 08:05:

IPX is still on my to-do list for RetroNAS. But I've got some nagging networking stuff I want to get out the door first - a basic LAN segmenter with firewall and DHCP server, and some PPP over serial stuff.

IPX/SPX, my days of using Novell Netware have served me well, considering how I was able to get a LAN going in Age of Empires 2. Nowadays it seems IPX/SPX is relegated to DOSBox.

twiz11 wrote on 2022-04-20, 22:45:

elvis wrote on 2022-04-15, 08:05:

IPX is still on my to-do list for RetroNAS. But I've got some nagging networking stuff I want to get out the door first - a basic LAN segmenter with firewall and DHCP server, and some PPP over serial stuff.

IPX/SPX, my days of using Novell Netware have served me well, considering how I was able to get a LAN going in Age of Empires 2. Nowadays it seems IPX/SPX is relegated to DOSBox.

Still pretty good for network drives on real DOS machines - the client (including NIC driver) uses less conventional/upper memory than EtherDFS leaving more for games or other TSRs while also giving you an IPX (and TCP/IP) stack for free if you want to play LAN games. Don't know what performance is like but I doubt it would be worse than the alternatives (EtherDFS, SMB). Its also perhaps the only option for OS/2 unless you have any of the special IBM network add-on bits which, prior to Warp 4, were sold separately (1.x, 2.x) or only included in the special Connect edition (Warp 3). Though I doubt OS/2 networking is relevant to many people, especially on "old" versions.