locking files

Grant Edwards grante at visi.com
Wed Feb 21 18:44:02 EST 2001


In article <97123p$ojg$1 at nntp6.u.washington.edu>, Donn Cave wrote:

>| to clarify: i am on a unix system, i have tried to use flock however when i
>| locked the file i was still able to read, write and copy the file, none of 
>| which i want to happen while the file is locked. while using the flock 
>| method i was using LOCK_EX. also the third party program is not going to be
>| controlled, written, or have anything to do with mine. am i just not using
>| flock properly or is there something else that might do the job? thank you.
>
>Basically, that's how file locking works.  

IOW, it doesn't.  ;)

Really -- file locking under Unix is a royal mess and always has been.
Throw NFS into the picture and it's pretty much hopeless.

>It's advisory, for the benefit of software components that are designed to
>work together.

And then it's rarely portable, and there are about seven people on the
planet that understand what syscalls work on what systems and how to use
them.

I am not among those seven.

Here's a quick hack: When you want to "lock" the file, rename it.  I think
that on most Unices and filesystems a rename is an atomic operation (not
sure, about that).  I don't know how you're going to tell if the other
program is using the file.

>But there is a variation that you can find supported on some filesystems,
>where in combination with an obscure permission mode on the file the lock
>becomes mandatory and effective against any and all I/O.  The permission
[...]
 flock(2), so it's up to the programmer to find out what kind of lock
>fcntl.flock() really gets, if the difference is important.

Donn may be among the seven.  ;)

-- 
Grant Edwards                   grante             Yow!  I hope the
                                  at               "Eurythmics" practice birth
                               visi.com            control...



More information about the Python-list mailing list