From: eric@daccess (Eric Ashley)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Information on PC-based NFS clients
Date: 8 Apr 92 02:28:28 GMT
Article-I.D.: daccess.9204080228.AA12462
Organization: The Internet


 >> In researching an article for a DBMS magazine, I need to collect some
 >> information about PC-based NFS clients.  The information I specifically
 >> need is whether or not each of the products available supports the
 >> translation of the DOS lock() function into a RPC lock request for proper
 >> client/server lock operations to occur via the Unix lock manager (lockd) in
 >> a multi-client environment. Obviously, if a package translates the lock()
 >> but ignores the response, I'd like to know that, as well.  If the RPC lock
 >> capability is available as an add-on to some other product, this
 >> information would be helpful, also.

>The question you ask quite simply is not a question of just the DOS NFS
>products on the market; but also one which encompasses the NFS server in
>question and the DOS application which is using the lock requests.

I have already specified the requirements of the server's lock manager.  A
complete System V.3 lock daemon will do what is required.

>Problem 1: PC based NFS locking is dependent on Version 3 of the
>Network Lock Manager; if your server doesn't have that you lose.

>Problem 2: PC based NFS locking uses an unsigned 32 bit offset and length
>for locking byte ranges in a SHARE RPC.  Lock daemons based on System
>V kernel lock daemon code use a 32 bit signed value to represent
>offset and length.  This means if your offset or length has the high
>bit set;i.e. 0x80000000 or higher; you lose.

Our locking mechanism is a file locking one.  In other words, every time you
lock data file X, the same byte range in that file is locked.  The same range
gets locked when you lock file Y.  The lock range will never be one that would
exceed the size of an unsigned long versus a signed long.

>Problem 3: Some DOS applications have oh so cleverly decided that using
>a lock of a phantom range is a really neat way of having interprocess
>communication.  One unnamed but very well known package has been seen to
>issue lock requests to lock 1 byte at offset FFFFFFFF to allow multiple
>clients to share a spreadsheet without overwriting the data.  In this case
>you lose.

This type of information is not my concern.  I am only providing our developer
community with a list of clients that should work correctly with our software.
It is not my intent to provide all the DOS NFS client information necessary for
a given user to determine if a particular NFS will suit ALL his file sharing
needs.

>As to the functionality of the commercial DOS and OS/2 NFS clients; I
>observed Sun's PC-NFS, Beame & Whiteside's NFS client, Wollongong's NFS
>product, Netmanage's Windows product and FTP Software's DOS and OS/2 product
>pass locking tests with correctly implemented lock daemons; I also
>saw our clients (and assume all others) fail against "broken" lock daemons;
>i.e. problems 1 & 2 above.

>Unfortunately your problems are much more likely to be server related than
>client related.

Again, I've already specified the Unix lock daemon requirements for use with
our software and have a list of OS vendors that include them and a list of
vendors that don't.  I just need to build the equivalent lists for the DOS
clients.

Thanks for the input,
Eric

===========================================================================
Eric Ashley                            Internet E-mail: ERIC@DACCESS.COM
Senior Support Specialist              Compu$erve:      Go DACCESS
Technical Services                     Office Works:    DATA_ACCESS/ERIC
Data Access Corporation/International  Telephone:       (305)238-0012 x2930
===========================================================================