[dokuwiki] Re: Proposal: FS#113, notify changes

Andreas Gohr wrote:

On Fri, 24 Jun 2005 21:06:24 -0500
Steven Danz <steven-danz@xxxxxxxxx> wrote:


Well, I started reading and it looks like flock() doesn't sound too reliable, and
more so in my case as -everything- here runs over NFS. From looking
at the comments
on Zend, it almost sounds like file locking in general might need some

review thanks
to file caching issues and new multi-threaded Apache servers. I'm looking over
http://us2.php.net/manual/en/function.flock.php
now for some ideas. Let me know what you think.


From the above page: 

 file locking with PHP over NFS shares simply does not work. Any
 attempt to use it will fail under any race condition.
 The only atomic file operation which is usable over NFS is mkdir()
 which will either create a folder or return a error status...
 So on NFS servers, forget flock(), use @mkdir()

So you could use mkdir to create a "lock file". I suggest to do this in a 
special lockfile directory instead doing it directly in the datadir. I'd like to move the 
lists of subscribed users out of the datadir, too.

So its sounding like even the current locking mechanism may need to migrate over to a mkdir mechanism as well? In looking at the current locking mechanism, it seems like two instances could write to the lock file, and read back their info, thanks to file caching in the OS and believe they both have the lock. Especially if the locks are across systems in a load balanced group of web servers, all pointing to shared file storage like NFS.

For the mail lists, would a 'mlists' directory at the same level as data, media, and attic be cleaner? From your 'uncluttering the cache' mail:

data/
|-- changes.log
|-- attic/
|-- media/
|-- data/
|-- mlists/
`-- cache/
   |-- xhtml/
   |-- instructions/
   |-- media/
   |-- locks/
   |-- purgefile
   `-- _htcookiesalt

Should locks be in cache or at the same level as attic, media, and data?  When 
I see a 'cache' directory, in theory, I would think that a user should be able 
to 'rm -rf cache/*' and  not effect the operation of the system, other then 
causing it to rebuild/repopulate the cache.  Locks don't quite fit in that 
category since deleting them could cause data to be lost since removing the 
locks could allow multiple people to write the same file at the same time.

Steven


I'll post another mail about that in a minute.

Andi


--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: