By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,617 Members | 1,751 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,617 IT Pros & Developers. It's quick & easy.

multiple clients updating same file in ftp

P: n/a
hi all

am updating the same file in ftp, through multiple clients, but am
scared that two clients may open the same file at a time, and try
updating, then the data updated by one data will be lost.
So i have to provide some lock mechanism to that file in ftp, so how
can i lock it, if one client opens it for updating, so that till it
gets relased it cannot be updated by other clients.
Could u please suggest me the simple solutions through the python code.

thanks for the help
Yogi

Jan 5 '06 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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.

cheers,
S

Jan 5 '06 #2

P: n/a
"st***************@gmail.com" <st***************@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. Exatly what that is will depend on your server, but things to
check on are rename and mkdir.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 5 '06 #3

P: n/a
why, that's the nicest thing anyone's said about me today - and
probably true, since I started coding on punch-cards...

s

Jan 5 '06 #4

P: n/a

Mike Meyer wrote:
"st***************@gmail.com" <st***************@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. Exatly 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.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.


Jan 7 '06 #5

P: n/a
"Fuzzyman" <fu******@gmail.com> writes:
Mike Meyer wrote:
"st***************@gmail.com" <st***************@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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Jan 7 '06 #6

P: n/a
Preface the update with a rename. If the rename fails,
someone else is updating the file, if it succeeds update
the file and rename back when finished.

Suggestion: ftp is not the best way to handle such a task.
Use a database, XMLRPC or sockets is probably a better
way.

-Larry Bates
mu*******@yahoo.com wrote:
hi all

am updating the same file in ftp, through multiple clients, but am
scared that two clients may open the same file at a time, and try
updating, then the data updated by one data will be lost.
So i have to provide some lock mechanism to that file in ftp, so how
can i lock it, if one client opens it for updating, so that till it
gets relased it cannot be updated by other clients.
Could u please suggest me the simple solutions through the python code.

thanks for the help
Yogi

Jan 10 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.