🚀 go-pugleaf

Greetings.

We are running PC-NFS on about 50 PCs. The lockd(8) under SunOS3.5 handles
DOS 3.3-style advisory locking rather well between peer clients (i.e., one
PC cannot open a file for write when another PC already has it open).

Meanwhile, we have some utilities which need to modify some of the files
that live in Sun directories that are mounted by PC clients through
PC-NFS. Naturally, we wanted to take advantage of the apparently
well-implemented advisory file locking and write our Unix application in a
way that made the lockd(8) daemon satisfied. That is, it would check for a
lock before molesting a file, set a lock if one were not already set, then
clear it when finished.

Good idea in principal, right? Basic systems integration.

The problem is that locks set under Unix (using either the more difficult
and verbose fcntl(2) method or the somewhat easier lockf(3) method) do not
appear to be honored by the client PCs.  And locks set by PC-NFS do not
appear to be honored by lock checks using either of those two methods
under SunOS. Hopes dashed.

Running rpc.lockd with debugging (set at level 10), I find this confirmed:
the diagnostics printed by the PC clients is significantly shorter and
quite different from that printed by the SunOS lock and release stuff. I
can send examples if anyone is interested.

Can anyone offer any pointers to this dilemma? Am I coding my test program
wrong? (I can send that, as well; it's brief.)

Surely it's likely that someone has been through this jungle before.

Thanks in advance!
		--Dwight Ernest
		  Technical Systems Coordinator
		  The Independent (Newspaper Publishing PLC)
		  40 City Road, London EC1Y 2DB
			  Phone: +44 1 956 1633
			  ...ukc!independent!dwight