Help: using msvcrt for file locking

[Sheila King]

On Sun, 26 Aug 2001 04:22:10 -0400, "Tim Peters" <tim.one at home.com>
wrote in comp.lang.python in article
<mailman.998814219.31022.python-list at python.org>:

:[Sheila King]

:> I've been pouring over the Active State site, as well. The win32
:> extensions do, apparently, provide access to the LockFile and LockFileEx
:> functions.
:> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65203
:>
:> It's just that I was hoping to accomplish this without requiring the use
:> of the win32 extensions. (Maybe it's silly of me, but I tend to want to
:> avoid requiring others to install stuff to use the code.)
:
:Sure!  You need to understand, though, that Python is coded in C, and C is
:of no help here:  C defines *nothing* about file locking. 

I understand that.

: That means
:there's nothing Python can build on cross-platform either.  Even if the only
:thing you cared about were Linux systems, you could spend many weeks
:learning all the subtleties involved with file-locking on it alone.  It's a
:mess.

<sigh> Thanks for the encouragement. No, I know you're just trying to be
honest about the whole thing.

:You're trying to solve a very difficult problem.  I don't know whether the
:recipe you found is reliable, but years of experience tell me that anything
:that short won't work as intended in all cases (for example, I see the
:recipe builds on flock on Unixish boxes, and that may be useless if a
:network file system gets involved).

OK, well I guess I'm not going to worry about the networking thing. For
one, it's beyond me. And for two, I don't expect my code to need to
access files remotely from the machine it is running on.

:Of course not.  But "msvcrt" means MicroSoft Visual C++ RunTime, and if you
:use *that* obscure module, then, yes, you had better know what you're doing.
:msvcrt is a module for people comfortable with MSVC; it's not suitable for
:others.  Indeed, there's *no* function in that module I'd recommend for
:non-expert use.

OK, so if we went with the win32all Win API extensions, are these better
documented and better understood ? Would it be possible to do more
reliable file locking with those libraries?

As you will see in this article (when it becomes available on Google):
http://groups.google.com/groups?as_umsgid=%3C0q4iotg9ld08s7850vv3dqfi2hnbefv015%404ax.com%3E

apparently msvcrt doesn't allow one to acquire a non-blocking lock?

:> ...
:> What you see above is the confusion of someone who is trying to learn
:> about file locking and handling concurrent access at the same time that
:> she is attempting to learn how Python handles it AND how to do it cross
:> platform. No more. No less.
:
:Python doesn't handle file locking.  Perl pretends to <wink>.  If I were you
:I'd try another approach (for example, if your program has control over
:access to the files of interest, you can invent your own locking
:*abstraction* in software and leave painful OS-specific gimmicks out of it
:entirely).


For CGI, I need file locking. The alternatives are (as I understand
them):

1. Have a server running, which controls access to the files, thus
ensuring that only one process can write to the files at a time.

2. Something dealing with sockets, where the CGI script tries to see if
a certain socket is listening to determine whether it has permission to
write to the file...details are hazy and I'm not going to look this one
up again right now.

3. Check whether a certain file exists to determine whether or not the
process can have permission to write to the files.

The problems with # 1 and 2, is that it requires a process running on
the web server all the time, and I am not allowed to do that on the
shared, community server where I host my website. (I don't think most
people who do not run a dedicated server are allowed to have processes
running in the background on the server.)

The problem with #3, is I've heard that is unreliable as well. Problems
with whether the file will be deleted or written if the program crashes.
Then, if the file is still there/missing, subsequent calls to the CGI
script will think that they have permission to write when they don't.
Or, the process may think that it can't have permission, when it can.
Etc...

Since in a CGI situation, you may have many processes running in
parallel, then "my program" doesn't control access to the files, since
there may be many instances of the program. Actually, this is what I
thought to do originally, but After going over # 1, 2, 3 above, I
thought...gee, this isn't going to work. Then, I found a really nifty
example in Mark Lutz Programming Python, Chapter 14 where he does a
shelf database implementation for his Book Errata website. He discusses
file locking in there, but only for a Unix-type platform.

I really don't see any way around file locking for the type of
application I'm trying to write. However, I guess after seeing all the
trouble with the msvcrt module, and how it doesn't even seem to allow
shared locking access to a file, that I will go ahead and use the
win32all extensions. I'm supposing that will allow better control?

--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/