multiple clients updating same file in ftp

Mike Meyer mwm at mired.org
Sat Jan 7 04:10:07 EST 2006


"Fuzzyman" <fuzzyman at gmail.com> writes:
> Mike Meyer wrote:
>> "stewart.midwinter at gmail.com" <stewart.midwinter at gmail.com> writes:
>> > here's a simple-minded suggestion: have the first client create a text
>> > file on the remote server, and delete it when it is finished updating.
>> > The second client can check for existence of this file before trying to
>> > update.
>> That's an old hack, dating back to at least Unix v6. The problem is
>> the window between "check for lock file" and "create lock file." The
>> solution is to use an atomic create-or-fail action for the lock
>> file. Exactly what that is will depend on your server, but things to
>> check on are rename and mkdir.
> mkdir is good - if the directory already exists an error will be
> raised, this means you don't need to check for it's existence (meaning
> a race condition in between checking and attempting to create). If two
> "mkdir"s occur simultaneously then it is up to the OS to return an
> error to one of them.

Except that some os designer (or the ftp server - remember, the OP is
talking to an FTP server to do this!) may decide that mkdir on an
existing directory isn't an error, since the directory exists
afterward. Rename can also work, but again depends on how the os and
FTP server decide to treat the case of renaming to an existing file.
There may be other alternatives as well.

If the OP weren't working through the FTP server, os.open with
os.O_CREAT|os.O_EXCL would do the trick.

          <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.



More information about the Python-list mailing list