Flock and file deletion

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I am wondering if this is possible. I have a file that is accessed by
multiple users and keeps track of activity (the file is polled by
flash every 2 seconds). As users leave, the flash program tells the
php program to remove them from the activity file, and as users access
this activity file, users who have timed out (haven't been heard from
in 60 seconds) are removed. Using a combination of flock, microsecond
sleeps, loops and the flash file repolling if it doesn't get a
completed result back,  I have been able to keep anyone from stepping
on each other.

The question I have is, when the last user exits, I want to delete the
file, but am afraid that the file deletion may step on a user just
coming in and remove their activity. I had the thought of, and this
may be totally stupid, to open the file for read, flock it and delete
it while open. The theory behind this is that the flock would stay
active till the php script ended and the file handle was closed. At
which point the other waiting user would be able to access the file
for writing. Does this make sense?

Bill H

Re: Flock and file deletion

Quoted text here. Click to load it

I presume here that two instances of the same user in the file is
something that must be avoided, as it constitutes "stepping on each
other".  Or if you mean two instances of *any* two users constitutes
"stepping on each other", that's just as bad, if not worse.

flock() locks a file.  It does not lock a file *name*.  If someone
takes the old file and does a rename() or remove() on the file or
rename()s the directory structure above it, you'll end up with a
locked old file under the wrong name (or no name), and later someone
may re-create a new file under the correct name.  There will be two
different files, and you won't see locks set in one on the other
one.  I suggest you think *VERY* carefully about deliberately
deleting the lock file, ever.  Truncating the lock file to zero
length may be acceptable.

Quoted text here. Click to load it

Yes, as you describe it, this is a real problem.  You may not see
screwups very often in practice, but they are possible.

Quoted text here. Click to load it

Nice try, but it has holes in it.  You failed to explain when
the file would get re-created after it is deleted.  Even then,
consider this:

Process A tries to delete the last user, A from the file.
Process B tries to add a user B to the file.
Process C tries to add the same user B to the file.

A opens old file.
A locks old file.
A observes that A is the last user in the file.
B opens old file.

B tries to lock old file, finds it busy, and waits.  (Or perhaps B doesn't
try to lock the file until A has closed/unlocked it).

A deletes old file.
A closes/unlocks old file.
B succeeds in locking old file.
B adds user B to the old file.
B unlocks old file.
C tries to open file, fails, noting it is not there, and re-creates it.
C locks new file.
C adds user B to the new file.
C unlocks new file.

Now you have two processes who each think they successfully added
user B to the file.  Do I hear feet being stepped on?

Re: Flock and file deletion

Bill H wrote:
Quoted text here. Click to load it

Make it easy on yourself.  Use a database.  That's what they're good at.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Flock and file deletion

Jerry Stuckle schreef:
Quoted text here. Click to load it

Excactly, avoid that flock() mess by using a database.
I did a lot of online gaming programming with Perl serverside using
files and filelocking to avoid concurrencyproblems.
Especially when you need access to multiple files this can cause a headache.
Man, was I glad when I learned how to use a database. :-)

Erwin Moller

Erwin Moller
Now dropping all postings from googlegroups.
Why? http://improve-usenet.org /

Re: Flock and file deletion

Quoted text here. Click to load it

It would probably be easier to just leave the file empty when there
are no users rather than deleting it altogether, as you'd then have to
recreate it when the first user comes back on.

A database is probably going to be a much better solution to this
problem than a file as most database engines have mechanisms to cope
with just this kind of problem.

Re: Flock and file deletion

Quoted text here. Click to load it

PHP's file handling does not handle contention well. You could
displace the lock to a different file but this is totally the wrong
way to solve the original problem - which is keeping track of user

The quickest route to the right way of doing things is to use a custom
database bound session handler.


Re: Flock and file deletion

Bill H wrote:

Quoted text here. Click to load it
Microsecond sleeps, loops and repolling equals "active waiting", which alone
is a recipe for disaster.

You should study something about concurrent programming (atomic calls,
critical sections, etc), learn how to push data from the server to the
flash clients (look for piggybacking and reverse ajax techniques), and
*then* (and only then) rethink the problem.

Else, you *will* step into race conditions, and your system will likely blow
up at some point.

Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Un ordenador no es un televisor ni un microondas, es una herramienta

Site Timeline