NFS on System V

[Guy Harris]

> Our concern is making the files portable between 4.2BSD based Celerity system
> and our new workstation. Can we remote mount the filesystem from 4.2 BSD
> based system onto the new System V based workstation usin NFS?

Assuming everybody did things correctly, there should be no problem;
other implementations of NFS on top of kernels based primarily on S5
can talk quite happily to implementations of NFS on top of kernels
based primarily on 4.2BSD.  Assuming the mostly-S5-based kernel
either

	1) implements SunOS's "getdirentries" or S5R3's "getdents" call,
	   or some such "get a directory entry" call (and the "directory
	   library" - "opendir", "readdir", etc. - is provided)

or

	2) uses some trick, such as the one alluded to in the "NFS
	   Portability" paper in the Atlanta USENIX proceedings, to
	   make "read"s on directories look (sorta kinda) like reads
	   on a V7-style directory

you shouldn't have a problem with directory formats, unless you have
files with names longer than 14 characters.  If the first approach is
taken, then applications written with the directory library (and that
don't otherwise assume that file names are no longer than 14
characters) should work fine no matter how long the file names on the
Celerity are.  If the second approach is taken, you may have trouble
with files that have names longer than 14 characters, but files with
14-character or shorter names should cause no problems.

You may also get surprises if the Celerity has files with inumbers
greater than 65535, since "ino_t" is an unsigned short on systems not
using the 4.2BSD file system.  In practice, however, you may not have
any such files (I'm sure somebody out there has created one, but I
doubt they're very common - I just tried "df -i" on a machine here
with a lot of files, and the largest "iused" was 32342).  Then again,
unless your application (or a library routine it calls) looks at the
i-numbers returned from directory reads or "stat"s, it won't even
notice.

Of course, if the S5 box uses the 4.2BSD, rather than the V7, file
system, neither of those two will be different.

"ustat" may or may not work on NFS file systems (it does on SunOS,
but not systems running the the Lachman Associates/The Instruction
Set S5R2 NFS).  (No, we did not change the arguments to "ustat"; if a
process on machine X does a "stat" or "fstat", and uses the "st_dev"
field in a call to "ustat", it will get the proper file system
statistics for the file system on which the file that was "stat"ted
or "fstat"ted resides.  We just don't guarantee that you can hand
"st_dev" to another machine and have *it* get the same results when
doing a "ustat" that you got....)

You won't be able to do a "utime(pathname, (struct utimbuf *)NULL)"
over the wire to the Celerity, since NFS does not include a "set the
modification and access times on the file to the current time if the
requestor either 1) owns the file or 2) has write permission on it".
Other "utime" calls should work.

You will probably also not be able to change the ownership of a file
on the Celerity from the S5 machine, unless they've changed their
UNIX to permit it.  This is as it should be; the "owner" of the file
system, i.e. the server, should decide whether to permit this or
not, and has the right to forbid it even if the client permits it.
Permitting it would cause problems with the disk quota mechanism.

You may or may not be able to use named pipes over the wire.  Some
NFS implementations (including SunOS's) support them, but I don't think
they all do so in the same fashion.

These are all pretty much "corner cases".  Most operations won't know
or care what flavor of UNIX is supplying the files.

> Another concern is about transfer of files through ftp, which I think
> should not have any problems. 

FTP is FTP; if there's a bug or other misfeature in one or the other
of the implementations, you may have a problem, but the flavor of
UNIX doesn't enter into it.