Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

    #2
    I do know that the FCB and file system handling of DR-DOS 5+ and Novell DOS (its successor) is very different from the "standard" MS/PC-DOS versions, so that may be the root cause.

    It does, however, have some nice extensions to the built-in commands (like XDEL), picked up by changes to the MS/PC-DOS (e.g. DEL) in later versions.

    Comment


      #3
      I would be very interested in a quick cookbook of a successful NFS setup, as I've been unsuccessful trying to do this several times in the past. MSLANMAN is simply too heavy for a 640k system, and doesn't support all cards, so an NFS solution that uses standard packet drivers would be great. The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.

      For example, you listed a URL but not the specific package you tested.
      Offering a bounty for:
      - A working Sanyo MBC-775 or Logabax 1600
      - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

      Comment


        #4
        Originally posted by WBST View Post
        I do know that the FCB and file system handling of DR-DOS 5+ and Novell DOS (its successor) is very different from the "standard" MS/PC-DOS versions, so that may be the root cause.
        Last night I upgraded my DR-DOS 6 installation to Caldara DOS 7, and, knock-on-wood, it looks like it's fixed the xcopy not making a directory issue. I discovered after my initial post that EtherDFS didn't work on DR-DOS 6 at all but it also works on 7 so apparently they fixed "something" to make it at least better to emulate the MS-DOS flavor.

        Just kicked off a full xcopy of my boot drive to NFS, I'll see what happens.
        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

        Comment


          #5
          Originally posted by Trixter View Post
          I would be very interested in a quick cookbook of a successful NFS setup, as I've been unsuccessful trying to do this several times in the past. MSLANMAN is simply too heavy for a 640k system, and doesn't support all cards, so an NFS solution that uses standard packet drivers would be great. The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.
          I'm currently using the xfs-191.zip; according to the *very* sketchy documentation I started with this version might need a "286 or higher", but it runs on my V-20 equipped HX. According to a (German language) thread I found there was a claim that the 1.8x versions will work on an 8088, but I'll admit my German is pretty rusty. I will probably try 1.8x again to see if there's any difference, I switched to the newer version in response to the problem I solved with SETVER and haven't gotten around to going back since 1.91 runs.

          Unfortunately "weight" still might be an issue with this solution. The xfskrnl that needs to be loaded takes almost 64k, which is *just* too big for what's left over on my 1000 HX with its UMB RAM board after loading DOS; I might barely make it fit on the 1000 EX. (Difference is 112k vs. 128k of upper memory.) If you can't get that kernel into upper memory and you need to have DOS low you're probably looking at a 500k-ish TPA. EtherDFS is thus far the reigning king of low memory usage I've found for Ethernet mountable filesharing, I'd love to know if there are other solutions in its ball park.

          The quick recipe for getting it going:

          1: I'm pretty sure you need NFS v2 support on the server side, which most distributions don't do by default anymore. I achieved this by modifying "/etc/defaults/nfs-kernel-server" (Ubuntu) to enable said support per this support thread; If you're running 18.04 or later look for "I had to hijack RPCNFSDCOUNT to get it to use NFS v2":

          RPCNFSDCOUNT="--nfs-version 2 8"

          2: The xfs documentation is kind of a... thing. The quick and dirty way to get it going is to modify the HOSTS file in the distribution to look like this:

          Code:
          10.1.1.1	gateway
          10.1.1.255	broadcast
          255.255.255.0	netmask
          	
          10.1.1.10     server		nfs-server
          10.1.1.20     myhost
          "myhost" is the name of the DOS box you're running it on. Assuming you don't care about trying to authenticate or print share with pcnfsd (a can of worms I have not opened yet) don't bother with the INIT script; A batch file that loads your packet driver and xfskrnl and runs the TCP/IP init should be fine:

          Code:
          @echo off
          rem XFS Version 1.71
          rem good luck loading xfskrnl high, is big
          
          loadhigh pnppd 0x60
          loadhigh xfskrnl 0x60
          
          rem xfstool will look in the HOSTS file for the gateway/broadcast/netmask entries
          rem and apply them to the host name you specify
          
          xfstool init myhost
          
          rem done
          Then you can try checking mounts with "showmnt server(name)", and then try mounting something:

          xfstool mount e: server:/path/on/server

          As noted in the docs, the tool will want to own your packet driver, but it provides a passthrough two ports higher than what it latches onto, IE, if you run the packetdriver at 0x60 you *should* be able to use the mTCP tools or whatever by pointing them at 0x62. I have not tried this yet.
          My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

          Comment


            #6
            I've used XFS 1.91 on my Deskpro 8086 with V-30 upgrade and Compaq MS-DOS 5.0 for a little while. I never was able to figure out the whole authentication thing, so it basically mounts the NFS drive read-only (the login part of the init script fails). But the thing that is kind of a deal breaker is the upper-case filename mangling. If a filename fits in the 8.3 format and is lower case on the server, it shows up as an unmangled filename under DOS. Anything else gets mapped to essentially random characters. But all my DOS files are upper case on my server so I found a script to rename all the files in a directory to lower case. Quite the hassle.

            There are also some incompatibilities with certain programs. I use PFM.COM, Paul's File Manager (if you worked at Compaq you used it and your fingers are still programmed to its keystrokes), but it crashes out any time it touches the mounted drive. PFM.COM works fine with MSNET. Other file operations will crash out on occasion, XCOPY and such.

            If I could figure out the authentication so I could write to the NFS server, at least it would make for another option to copy files back and forth. As it is, mTCP is the solution of choice.

            Comment


              #7
              For whatever it's worth, booted under Caldara DOS 7 an XCOPY of about 120MB of files just completed with zero errors or premature pooping out. It's probably worth noting, though, that this doesn't seem to be a particularly *fast* solution. That copy took something around 4 hours, so that's around half a meg a minute, or only 8-9k or so a second? So...

              Originally posted by Trixter View Post
              The most amount of storage I've been able to attach to an 808x system is 8GB, but I have a use case for attaching more and would love to test it.
              Unless your XT is a lot faster than mine you'll probably grow pretty old and gray copying more than 8GB.

              (For comparison, I ran mtcp's spdtest after doing the copy and my connection to the server benched at about 64k/sec upload, 56k/sec download. So wire speed it sure isn't. It has an option to turn off checksumming, maybe that makes it faster. And, for the record, running through the XFSKRNL's packet proxy didn't work for mtcp programs, I had to use xfstool to disarm the NFS share for speedtest to work.)

              But, again, it does seem to "work". The mounted filesystem had about 77gigs free on it, I have no idea how much you could *actually* manipulate from the attached DOS box.
              Last edited by Eudimorphodon; June 5, 2020, 06:45 PM.
              My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

              Comment


                #8
                Originally posted by resman View Post
                If I could figure out the authentication so I could write to the NFS server, at least it would make for another option to copy files back and forth. As it is, mTCP is the solution of choice.
                Writing works fine for me with no authentication by just exporting it with the right options on the server. I did note the file name limitations, so it's definitely not ideal if other OSes touch the same share.

                Calling the authentication stage is an entirely optional layer; any security you're going to get out of it is practically speaking kind of a joke. I'm mildly skeptical about my chances of even getting pcnfsd to work on a modern Linux machine, nobody packages it anymore. Maybe it works?
                My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                Comment


                  #9
                  Originally posted by resman View Post
                  Other file operations will crash out on occasion, XCOPY and such.
                  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. There's no error message, just at some random point during the copy XCOPY just poops out and tells me it's copied x-many files which is some random-sized subset of the full copy. I assumed it might be some limitation with XCOPY until I swapped my SD card hard drive for a bigger one with multiple partitions and did an XCOPY of all of C:\ to a directory on D: and it completed 100%

                  I've tried the same XCOPY test with XFS and the same thing happened, XCOPY just bailed at a random spot, so it seems to be a general problem with network drives or... something? This is under PC-DOS 7/2000; I've been meaning to but haven't prepped a boot disk to try this with other Microsoft-based DOS-es like 6.22 or 5 to see if this is a PC-DOS specific thing. It happens on two different machines with the same OS build on them.

                  Since XCOPY doesn't return an error message I have *no idea* what the failure is, so far as it looks it's like it's just decided it's copied enough files today and it's done.
                  My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                  Comment


                    #10
                    So you've inspired me to return to XFS. I just made a new share and gave the directory full permission to everyone. Not something I was willing to do to my home directory. Lo and behold, XFS can read and write to it. I see the user/group of nobody/nogroup writing to it. So that will be a workable solution for the times I need it.

                    Thanks for the inspiration to continue fighting it.

                    One of the things with XCOPY that I believe causes pain is the filename remapping somehow comes into play and the same mangled name is re-used causing infinite recursion. Just a thought. PFM.COM crashes out with: "runtime error 200 at 0102:145C." (just typing "DIR" on the drive will show that at the end of the listing) whenever touching the mounted drive. Whatever that means. On further review, it appears to get that error when displaying the free bytes on the volume. Hmmm.
                    Last edited by resman; June 5, 2020, 07:27 PM.

                    Comment


                      #11
                      Originally posted by Eudimorphodon View Post
                      Unless your XT is a lot faster than mine you'll probably grow pretty old and gray copying more than 8GB.
                      I don't want to copy that much -- I want that much (and more) accessible on-demand. For reasons.
                      Offering a bounty for:
                      - A working Sanyo MBC-775 or Logabax 1600
                      - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

                      Comment


                        #12
                        Originally posted by resman View Post
                        So you've inspired me to return to XFS. I just made a new share and gave the directory full permission to everyone. Not something I was willing to do to my home directory.
                        Heh. You could tell the server to lock down the allowed clients to a specific IP, but, yeah, generally speaking I'd say any network service you run for such ancient and fundamentally insecure purposes you should either consider a confidentiality-free zone or needs to be strictly air-gapped.
                        My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                        Comment


                          #13
                          Originally posted by Trixter View Post
                          I don't want to copy that much -- I want that much (and more) accessible on-demand. For reasons.
                          If it's mostly going to be reading then I'd definitely look into seeing if some of the no-checksum and other options speed it up. I was also running over a combination of wifi and a known-cruddy ethernet bridge, which may have made it *particularly* troublesome.

                          (To a wired-on-the-same-segment host Speedtest manages about 50% better results, which gives you an idea of how awful that ethernet bridge is. Was too lazy to move a server to the other side for initial smoke tests.)
                          My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs Also: Blogspot

                          Comment


                            #14
                            I have using XFS v1.91 for years and it's an awesome piece of software. Here is a howto to setup it:

                            http://wiki.freedos.org/wiki/index.php/NFS

                            The howto mentions a specific 8086 version which I was never able to find ...

                            This is my configuration:
                            * Client side
                            I use this to start/stop the client
                            Code:
                            @ECHO OFF
                            :: XFS start/stop script
                            IF .%1 == . GOTO start
                            IF .%1 == .STOP GOTO stop
                            IF .%1 == .stop GOTO stop
                            
                            :start
                            :: use your own packet driver
                            loadhigh d:\drivers\pcipkt 0x60
                            ::loadhigh d:\xfs\winpkt 0x60
                            loadhigh d:\xfs\xfskrnl 0x60
                            d:\xfs\xfstool @init
                            GOTO end
                            
                            :stop
                            d:\xfs\xfstool @fin
                            ::d:\xfs\winpkt -u
                            :: use your own packet driver
                            d:\drivers\pcipkt -u
                            
                            :end
                            Run startnet STOP to unload the hole thing and free the memory.

                            This is the "init" file
                            Code:
                            #
                            # XFS Start Command Script
                            
                            init i486 sm=255.255.255.0 gw=192.168.2.1 csum=off
                            
                            # authentication
                            # You need the pcnfsd daemon for this to work
                            #pcnfsd debian
                            #login
                            
                            mount z: debian:/srv/nfs
                            mount lpt1: debian:canon timeo=30
                            
                            show
                            rdate debian
                            and this is the "unload" script
                            Code:
                            #
                            # XFS Stop Command Script
                            #
                            
                            show
                            umount all
                            #logout
                            unload
                            You also have to configure a hosts file on the client to resolve host names (i.e. my nfs server "debian" is 191.168.2.6)

                            * Server side:
                            You need to configure an /etc/exports file:

                            Code:
                            # /etc/exports: the access control list for filesystems which may be exported
                            #		to NFS clients.  See exports(5).
                            #
                            /srv/nfs       192.168.2.0/24(rw,sync,no_subtree_check,all_squash,anongid=999)
                            192.168.2.0 is my home network. I map all NFS users to group "share" because I have the group suid bit enabled in directory /srv/nfs to preserve the group ownership on newly created files.

                            Code:
                            $ ls -l /srv/
                            total 24
                            drwxrwsr-T 6 nobody share 4096 may 30 08:13 nfs
                            You only need the pcnfsd daemon to authenticate users and print. I have a debian (and RPM) script to build such packages.
                            Last edited by dieymir; June 5, 2020, 11:01 PM.

                            Comment


                              #15
                              I forgot to upload the debian package sources. Here it is:

                              pcnfsd.zip

                              to build it:

                              1) Extract the contents of the zip file
                              2) Go to pcnfsd/pcnfsd-2.0.build
                              3) Run dpkg-buildpackage in that directory

                              it will create a pcnfsd_2.0-4_amd64.deb package in pcnfsd with these contents:

                              Code:
                              $ dpkg -L pcnfsd
                              /.
                              /etc
                              /etc/init.d
                              /etc/init.d/pcnfsd
                              /etc/pcnfsd.conf
                              /usr
                              /usr/man
                              /usr/man/man8
                              /usr/man/man8/rpc.pcnfsd.8.gz
                              /usr/sbin
                              /usr/sbin/rpc.pcnfsd
                              /usr/share
                              /usr/share/doc
                              /usr/share/doc/pcnfsd
                              /usr/share/doc/pcnfsd/changelog.Debian.gz
                              /usr/share/doc/pcnfsd/copyright
                              /var
                              /var/spool
                              /var/spool/pcnfs
                              This works with debian 7 I haven't tested it with more current versions.

                              I have also a RPM source package to build pcnfsd under RedHat/CentOS but I wasn't able to find it.

                              Comment

                              Working...
                              X