Fix for issue with DOS NFS client (XFS 1.x) on PC-DOS 7. Also, DR-DOS 6.0 issue

[dieymir]

They are messed up completely.

 

[resman]

Here is a script I found to lower-case all the files in a directory:

for i in $( ls | grep [A-Z] ); do mv -i $i `echo $i | tr 'A-Z' 'a-z'`; done

There should be a way to do this recursively, but I suck at scripts.

 

[Eudimorphodon]

On another matter, I tested all 1.8x versions I could find and definitevely they don't work with 8086/8088 processors.

I guess that magical version of 1.91 that supposedly existed to support 8088 that's mentioned in the FreeDOS document has been completely lost to history.

 

[Eudimorphodon]

Re: my griping about XCOPY just randomly bailing:

So, this is a thing that actually got me looking at alternatives to EtherDFS, because I've discovered that if I try doing a *BIG* XCOPY to a mounted EtherDFS share it usually fails.

I set up a laptop on the same wired segment as the DOS machine to do tests against instead of having to transverse Wifi and a known treacherous powerline bridge and after that I was able to do a 95MB full-disk copy test against both etherdfs and nfs, so I guess what I was seeing was link-level errors. It's odd no user-visible "disk error" messages get thrown, XCOPY just silently pretends it's done, but I suppose I should set expectations accordingly.

Anyway, with a wired and seemingly reliable link the rough numbers for throughput for a bulk XCOPY appear to shake up as roughly:

EtherDFS: 19 KB/s
XFS: 12 KB/s

(XFS was initialized with "csum=0".)

For reference, raw "spdtest.exe" results for the network interface:

send: 75.2 KB/s
receive: 85.8 KB/s

XFS definitely seems to have higher overhead, but it's not as much as I thought at first; on a faster computer it might be a wash. Copying disk partition to disk partition actually only finished at about 43 KB/s despite various benchmarks claiming my XTIDE card scores read speeds of nearly 500K/sec, so clearly doing a long series of actual real-world operations on a computer this slow is more expensive than whatever the benchmarks are doing.

(I *do* have a particularly slow and ancient flash card that DISKTEST.EXE says has a terrible IOPS score in there right now. I guess I'll have to run the same tests on a newer card I know scores much better in the IOPS department to see how that changes things.)

 

[Trixter]

I guess that magical version of 1.91 that supposedly existed to support 8088 that's mentioned in the FreeDOS document has been completely lost to history.

I took a look at the code and it's compiled Turbo Pascal with $G+ (turn on 286 optimizations). The main difficulty in trying to patch the code for 808x is that all procedures use ENTER/LEAVE; trying to convert these to 808x equivalents means trying to optimize for size at least 8 bytes in each procedure and a quick look shows there isn't room for that (there's also PUSH immed. which would need to be converted too). So the only way we'll get an 808x version of this is either to disassemble the entire program to try to fix and reassemble it, or track down the author and ask him for the source.

 

[resman]

I took a look at the code and it's compiled Turbo Pascal with $G+ (turn on 286 optimizations). The main difficulty in trying to patch the code for 808x is that all procedures use ENTER/LEAVE; trying to convert these to 808x equivalents means trying to optimize for size at least 8 bytes in each procedure and a quick look shows there isn't room for that (there's also PUSH immed. which would need to be converted too). So the only way we'll get an 808x version of this is either to disassemble the entire program to try to fix and reassemble it, or track down the author and ask him for the source.

That explains the error 200 I'm getting while calculating free space. Although I don't believe the divide-by-zero error is due to being too fast (7.16 MHz v-30), it could be the 4 terabytes of free space on my server not being accounted for properly in XFS. Anyone else seeing this error?

 

[Eudimorphodon]

it could be the 4 terabytes of free space on my server not being accounted for properly in XFS. Anyone else seeing this error?

The NFS share I'm hitting with my box "only" has about 77GB free on it, but when I do a DIR on the mount with DOS the returned value doesn't seem to have anything to do with the actual amount of free space, so I suspect once you pass some size well short of 4TB it just rolls over. Out of curiosity I tried a DIR under both PC-DOS7 and DR-DOS7 and they both claim it's a 4GB disk with 3,2221,225,472 bytes free.

For laughs I used dd /dev/zero to create a 5000 megabyte file in what becomes the root directory of the mounted drive; a DIR shows DOS thinking the resulting file is 947,912,704 bytes (which I'm willing to bet a nickel without checking is 5000 megabytes minus 4096 megabytes) and it's saying the free space is 2,281,701,376. So... I bet if I make a 3.2-ish GB file instead it's going to say I have 4GB free space because it's cutting it off at a 32 bit signed integer. Let's see...

Yeah, that's it. If I make a file the right size I can get it to say I have more disk space by filling space up, so... my guess is it doesn't have any idea you have 4TB of free space, unless your NFS server is doing something differently. Are you allowing protocol V2?

 

[resman]

... my guess is it doesn't have any idea you have 4TB of free space, unless your NFS server is doing something differently. Are you allowing protocol V2?

I wouldn't expect it to know it has that much free space, I'm just wondering why its trying to divide by zero. I would take nonsense free space over divide-by-zero. Maybe I'll try and patch some NOPs over the divide instruction. It's on an NFS v2, but using the kernel NFS server. I suppose I could try pcnfsd and hope it doesn't break my other ancient NFS clients.

 

[Eudimorphodon]

It's on an NFS v2, but using the kernel NFS server. I suppose I could try pcnfsd and hope it doesn't break my other ancient NFS clients.

It's the kernel NFS server I'm using, I haven't tried setting up PCNFSD yet. (I think even if you install that it's still going to be the kernel server that's doing the actual file sharing, I think pcnfsd is just the authentication and print sharing services.)

It does seem really unlikely it could be that speed-related divide by zero thing, but for laughs have you tried running one of the various patchers for turbo pascal executables? (I'm running a V20 at the same clock, though, so... yeah, it seems like a stretch.)

 

[dieymir]

For me the best of xfs is that you can load it, mount the nfs share, do your stuff and unload the whole thing without rebooting. It would be really nice to be able to do the same on XTs

 

[leftygolfer32]

PKTMUX does indeed work. It adds another 19k or so of resident software, but since XFSKRL doesn't fit in upper memory on my machine anyway there's no net damage, I guess.

Under PC-DOS 7 on a machine with 624k base memory (yay Tandy) and 112k upper memory the total damage with an NFS share mounted and the packet redirector set up for MTCP is 564,864 bytes conventional free sitting at the DOS prompt. (552k) Could be better, but I've seen much worse.

You do have to be very cautious about filenames on the NFS side, that is most definitely a thing.

@Eudimorphodon, apologies for bringing this thread back from the dead, but I happened to stumble upon this while googling for a solution. I've recently acquired a Tandy1000 TX and attempting to do a similar thing. Mounting an NFS share works, as do the mTCP applications, but not both at the same time. I tried configuring PKTMUX as part of my xfs startup bat file but I know I'm configuring something incorrectly. Would it be possible to share how you accomplished the packet redirection for mTCP?

 

[leftygolfer32]

@Eudimorphodon, apologies for bringing this thread back from the dead, but I happened to stumble upon this while googling for a solution. I've recently acquired a Tandy1000 TX and attempting to do a similar thing. Mounting an NFS share works, as do the mTCP applications, but not both at the same time. I tried configuring PKTMUX as part of my xfs startup bat file but I know I'm configuring something incorrectly. Would it be possible to share how you accomplished the packet redirection for mTCP?

Nevermind, I figured it out.