[dokuwiki] Re: Proposal: FS#113, notify changes
- From: Steven Danz <steven-danz@xxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sat, 25 Jun 2005 12:39:17 -0500
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:
