🚀 go-pugleaf

I've rebuilt my emacs-19.27 with Karl Berry's NFS filelocking patch.
It isn't as robust as it could be as it doesn't use the visited file's
truename as the basis for the lockfile name.

For example, in a junk directory do the following:-

	touch junk.junk
	ln -s junk.junk junk2.junk

Now edit junk.junk and junk2.junk from 2 separate emacs processes.

Modify junk.junk - the lockfile .#junk.junk gets created.

Modify junk2.junk - no error is signalled.  Instead, lockfile
.#junk2.junk gets created.

Of course, emacs still does its modification time checking when you
attempt to save either buffer, but this is catching the problem later
than it could be caught it the lockfile was based in the file's
truename.


Just to get into the religious debate about whether this is The Right
Way to do file locking under NFS, here are a couple of points I'd like
to make:-

1)	IT WORKS! (most of the time, directory permissions being the
	stumbling block).

2)	Emacs has already set a precedent of assuming that it can
	create files in the visited file's directory.  This is how it
	handles backup and autosave files (yes, I do know that backup
	files go to the user's home directory if the file's directory
	is not writable).

3)	In the event of Emacs being unable to create a lockfile there
	is still the fallback check on file modification times, so
	Karl's changes don't make things any worse than they are now.

--
Kevin