🚀 go-pugleaf

I just found the notification information in the V1.4 preferences docs,
and I think it's generally good.  FileRequester people will love it.
Here's a summary...

You can ask to be notified when a file or directoy changes.  In the
case of a file, you get notified when it's closed after a write.
You fill out a Notify request structure and pass it to StartNotify()
(or do the equivalent packet thingie).  You aren't allowed to mess
with it until you call EndNotify().

You can be notified by signal (when the change occurs, your process gets
a certain signal, simple & useful for file requesters and the like,
which only want one thing at a time) or by a message, which sends a
message giving more information.  With the message version, you can
ask not to be notified again until you've replied to the message.

You can also have part of the file you're interested in copied to a
buffer.  This has race conditions unless you use the only-one-message-at-
a-time option.

Off hand, I can't think of any real problems implementing this in a network
environment.  Good job, Steve!

(And I apologise if my comment about ExAll() was a bit abrasive - I was
in a *really* bad mood about LockFromFH().  What I said is mostly true,
but there are lots nicer ways to say it.  Since the ExNext() call exists,
implementing a file system is a royal pain in the ass.  I can't think of
a way to improve the situation by adding more features, only by deleting
ExNext().  So just please don't make our lives harder.  Thanks!)

((But my nasty comments about hard links still apply - what the hell is
going on here?  Hard links means that a file does not have a unique name.
Maybe if you described how you intend to implement it by adding features
to the current DOS, I'd understand.))
-- 
	-Colin