Eudimorphodon
Veteran Member
This started as a request for help, but halfway through typing it I had an idea, tried it, and it worked. Maybe it'll be of some use to someone.
So, I started test driving alternatives to EtherDFS as a network file system for my DOS PCs. Saw a quick howto for doing NFS over a standard packet driver using XFS, tracked down a source of several versions here:
ftp://ftp.cc.umanitoba.ca/software/pc_network/
Spent some time hitting the linux server with a shoe to get it to serve a sufficiently old and insecure version of NFS, but I think I have that sorted out. Here's the problem I hit: I was able to load the XFSKRNL.EXE pointing at my packet driver at 0x60. Also had no problems running "XFSTOOL init" (after setting up an apropos HOSTS file) and I could run the SHOWMNT command against the server to see what mounts it's exporting. However, after running a "mount" command I'd get an "invalid drive specification" attempting to actually use the mount XFS saw as present.
Because I have it set up for a dual boot I went into DR-DOS 6.0 and tried the same spiel, and under that it worked. (Mostly, I'll get to that.) The fix I tried, and seems to work, for PC-DOS was to use setver to set:
XFSKRNL.EXE 5.00
XFSTOOL.EXE 5.00
I doubt both are strictly necessary, I'd hazard a guess just setting it for the XFSKRNL.EXE binary would be enough since I think that's where the actual redirector lives.
Running a full-disk XCOPY to the network now to see how it holds up. Trying to do this test under DR-DOS revealed what seems to be a bug in either XFS or the DR-DOS xcopy command: doing an "xcopy /s /e source:*.*" will only copy the files in the starting directory, when it has to create a directory it fails with a "path not found" message. (Which of course seems like a non sequitur given it should be the one creating the directory. If you create the directory for it and run it again it descends into it and copies the files... and then fails on the next "missing" target directory.)
Now that I have PC-DOS working its XCOPY doesn't seem to have that problem. Maybe it has others, that's a real possibility.
So, I started test driving alternatives to EtherDFS as a network file system for my DOS PCs. Saw a quick howto for doing NFS over a standard packet driver using XFS, tracked down a source of several versions here:
ftp://ftp.cc.umanitoba.ca/software/pc_network/
Spent some time hitting the linux server with a shoe to get it to serve a sufficiently old and insecure version of NFS, but I think I have that sorted out. Here's the problem I hit: I was able to load the XFSKRNL.EXE pointing at my packet driver at 0x60. Also had no problems running "XFSTOOL init" (after setting up an apropos HOSTS file) and I could run the SHOWMNT command against the server to see what mounts it's exporting. However, after running a "mount" command I'd get an "invalid drive specification" attempting to actually use the mount XFS saw as present.
Because I have it set up for a dual boot I went into DR-DOS 6.0 and tried the same spiel, and under that it worked. (Mostly, I'll get to that.) The fix I tried, and seems to work, for PC-DOS was to use setver to set:
XFSKRNL.EXE 5.00
XFSTOOL.EXE 5.00
I doubt both are strictly necessary, I'd hazard a guess just setting it for the XFSKRNL.EXE binary would be enough since I think that's where the actual redirector lives.
Running a full-disk XCOPY to the network now to see how it holds up. Trying to do this test under DR-DOS revealed what seems to be a bug in either XFS or the DR-DOS xcopy command: doing an "xcopy /s /e source:*.*" will only copy the files in the starting directory, when it has to create a directory it fails with a "path not found" message. (Which of course seems like a non sequitur given it should be the one creating the directory. If you create the directory for it and run it again it descends into it and copies the files... and then fails on the next "missing" target directory.)
Now that I have PC-DOS working its XCOPY doesn't seem to have that problem. Maybe it has others, that's a real possibility.