Re: [TWiki-Dev] Recent problems.

[Nicholas L. <nj....@ki...>]

> Lee pointed out that TWiki is not really ready for NFS.  There is a
> recipe in the Ram that makes an attempt to address network file locking
> (7.21. Program: netlock, pp. 264-266) BUT the authors don't appear to have
> much faith that it will work no matter what.  It may be the best hope
> for now.

NFS is like that I guess.

The only issue at the moment AFAI can tell with NFS and loaded balanced
server like sourceforge have at the moment is if a user (browser) stops and
restarts a save attempt.  It can become a race condition if the web/nfs
servers are loaded. TWiki's soft locking should be sufficent in most other
cases.

One potential way around it is to do something like qmail: save to
WebName.txt:User.PID.Time, then rename to WebName.txt.

All stuff I'm trying nutting out in my head at the moment for the
TWiki::Store package.

Of course the other problem I'm not so sure about is how 'NFS-safe' is rcs.

> Currently, I'm trying to make the netlock work with TWiki; but I'll
> abandon that if we are going to end up hosting elsewhere for a while.
> (We'll end up having to address this, regardless.)  Should I keep
> going?

There are potentially two points of issue:  saveFile and the write to
".changes" in saveTopic.

The first is probably alright currently because of the topic locking. The
later generally because writes are are rare.  However, a couple flocks at
those two locations aren't going to hunt anything.

Since the web enviroment is pretty straightforward a BLOCKING flock should
be sufficent.  In the worse case a user will reload, and the CGI exiting
will close any open file handles/locks.  Closing files handles in mod_perl
and flocks in win32 is a different issue.


Nicholas