From: keith@novell.com (Keith Brown)
Newsgroups: comp.dcom.lans.ethernet,comp.sys.novell
Subject: Re: Problems with Novell NFS and Verity TOPIC
Keywords: novell nfs topic
Date: 6 Apr 92 02:58:37 GMT
Organization: Novell, Inc. San Jose, California

In article <1992Apr3.171300.26954@wyvern.twuug.com> tmanos@wyvern.twuug.com (Tom Manos) writes:
>We are experiencing a significant number of problems with
>erroneous dates and invalid owners of files created on the NFS
>volume on the NOVELL file server.
> [... Stuff Deleted ...]
>Intermittently, the owner of an existing file will be changed to
>4294967294 or new files that are created will have this same
>number instead of a valid owner name.

When we unleashed NetWare NFS on the world at large, I'm not sure any
of us realised it was going to become probably the most popular
UNIX<->DOS IPC mechanism in existance! And to think of all the cash
Sun spend on marketing RPC when most of the planet seem to be quite
happy with open(), close(), read(), and write() :-)

Well anyways, here is the scoop. The DOS piece of your "Verity Topic"
application isn't opening the files on the server for sharing, consequently
NetWare NFS is unable to get at 'em when the DOS machines have 'em
open. Also, when NetWare NFS has the files open, the DOS machines
open() calls will fail.

Thanks to Microsoft, its actually a little more complicated than this.
There are now no less than 3 file open calls in MS-DOS 5.0 (Microsoft
got it wrong on two previous occasions :-)). There is the old DOS 1.0
call (INT 21h, subfunction 0x0F) which nobody in their right skull
uses anymore. I doubt your "Verity Topic" uses this unless you bought
the app in 1984 and never upgraded it. Then, there is the newer file
open call (INT 21h, subfunction 0x3D) which got introduced in DOS 2.X.
Unlike its predecessor, which used things called File Control Blocks to
control and manage open files, 0x3D uses the file handle IO model
which Microsoft "ripped off" from UNIX. This is the call that most
current DOS applications use and almost certainly is what this
"Verity Topic" thing uses.

This call allows you to open files with several sharing modes which, in
order to use (if you want them to actually work), you have to load an
extra piece of DOS embodied in the SHARE.EXE program. Why this should
be the case, I have no idea! Seems stoopid but thats the way it is.
Given SHARE.EXE is sitting in memory doing its thing, you can use
the 0x3D open file call to open existing files as shareable by goofing
with the top 4 bits of the 'al' register before you make the call.

These are the shareing modes and how they work with NetWare NFS:

1) SHARE COMPATIBILITY MODE (top 4 bits of al = 0)
   This is otherwise known as the "I'm far too stupid to know about
   other processes and networks so just give me the whole damn file to
   myself, thanks!" mode. This is undoubtedly how your app is opening
   the files (or trying to). When a DOS app has a file open in
   this mode, NetWare NFS can't get at the file or its directory
   entry and so niether can the UNIX clients apps we are servicing.
   This is true the other way round too.

2) SHARE DENY READ/WRITE (top 4 bits of al = 0001)
   While a DOS app is holding the file open in this mode, UNIX clients
   will still be able to read the file (its kind of debatable whether
   they should be able to or not) but they won't be able to write to
   the file regardless of the permissions in the NFS namespace. If you
   try, you'll get a permission denied error on the UNIX side and
   an accompanying ugly message on the NetWare NFS messages screen on
   the system console (we need to fix this as the message we print
   isn't very helpful and its not even complete! Sorry.).

3) SHARE DENY WRITE (top 4 bits of al = 0010)
   Works exactly like SHARE DENY READ/WRITE from the NetWare NFS / UNIX
   perspective (ugly message 'n all).

4) SHARE DENY READ (top 4 bits of al = 0011)
   UNIX systems will be able to read and write the file to their hearts
   content when DOS systems are holding a file open in this mode. No ugly
   messages, no access denials, nut'in. Great mode! I'd recommend it
   to anyone.

5) SHARE DENY NONE (top 4 bits of al = 0100)
   Even better than SHARE DENY READ mode, if that were possible!

However, like I said, Microsoft blew it again. The 0x3d open call can
only open existing files, it can't create new files. Microsoft
supply and additional create file call (subfunction 0x3C) to do that.

Now, here's the bummer. The create call leaves the new file open in
SHARE COMPATIBILITY mode and there's nothing you can do about it other
than immediately close the newly created file and reopen it for
sharing using 0x3D. I doubt very many DOS apps go to the trouble of
doing this when they create new files. So, when the DOS piece of this
"Verity Topic" thing first creates a file on the server and starts writing
to it, UNIX's efforts to pick up the file will fail until its closed
from the DOS side. Nasty! The DOS app could be written in such a way as to
make the DOS/UNIX "collision" improbable (ie. quickly create the file,
close it then reopen it SHARE DENY NONE for writing) but the probability
of a headbutt at the server will never be nill.

Relief is nigh. There is a brand spanking new open file call in DOS
(not sure if it was in DOS 4.X but it's certainly in DOS 5.X). Microsoft
may finally have got it right on INT 21h subfunction 0x6C. This call
not only opens files but can create 'em too *and* its cabable of
creating the files and leaving them open in the sharable modes.
Much, much better. Now if only some DOS applications would use it!

>We've heard that the implementation of the NOVELL NFS NLM may not
>be a true "stateless environment", meaning that the NLM does not
>write out file structure information when it changes.

Well, we don't do synchronous writes by default for performance
reasons. If this makes you twitch you can just modify the "CACHE_WRITETHROUGH"
parameter to on and we're as stateless as everyone else.

>One way we
>have reduced the number of errors was to set the "aging_interval"
>parameter to the minimum setting of 1 second.

Yes. This can provide some relief but really you need to get on to
these Verity people about their programming techniques. Your description
of the app makes it sound like its actually been written to do this
stuff via NetWare NFS which makes me disappointed that their programmers
didn't cotton on to these problems and write their code accordingly.
Its not hard!

Keith
-
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
2180 Fortune Dr, San Jose, California 95131      Net:   keith@novell.COM