"The Natural Philosopher" wrote in message
...
Bob Eager wrote:
On Wed, 26 Sep 2007 20:55:57 UTC, Andy Hall wrote:

SMB to a Linux server, or servers. TCP conns need to be 'kept alive'

NFS is probably better, but I loathe it.
Depends what you are doing. I've never had an issue so I presume that
any connections re-establish on their own which seems reasonable.

Actually, NFS is stateless and connectionless. That's one of the reasons
locking is so hard, and why caching is also problematical.
and why it survives a network outage or a machine going down.

And why it screws up royally if a machine editing a file leaves a lock on
it and goes down..


Its worse than that.. there isn't really any 100% safe mechanism to create
the lock file and be absolutely certain that your process created the lock.
The usual one was to use the PID of the process so there was a smaller
chance of two processes with the same PID creating the lock at the same
time.
Programmers obviously hadn't met Murphy. ;-)

I did meet Murphy BTW as I was designing a Unix system for a telephone
exchange that had upto 16 diskless Unix SBCs booting at the same time from
the same server with all the clients using NFS. Needless to say all the
application processes had the same PID so that locking mechanism didn't last
very long even though it did take some programmers a long time to accept
that just because it works on a random collection of Sun workstations
doesn't mean its going to work everywhere. Relying on user randomization
like most NFS applications appeared to do at the time doesn't work when
there aren't any users.

A question for you Unix/Linux code writers out there.. do applications still
use the same mechanism for locks on NFS or has someone created a
significantly better mechanism?