At 7:39 +0900 4/6/05, Joel Rees wrote:
On 2005.6.4, at 04:31 AM, Ken Williams wrote:
Actually, it *would* entirely solve the problem. Renaming a file
is an atomic operation, there's no point at which anybody could
get a partial file. People still reading the old file would be
fine too, even if the rename happened while they're in the middle
of reading; the old file is readable until they close it.
Peter pointed out in a private email that this isn't reliable using
FTP's rename functionality
I'd like a peek at what he wrote, if nobody minds.
Sorry, I was trying to reduce the noise as we drift further and
further off topic, but it seems ti just added more.
At 23:27 +0800 3/6/05, Peter N Lewis wrote:
We're getting a bit too esoteric to continue on the list, but this
depends on the FTP server allowing rename/overwrite, which is far
from guaranteed, even under unix. There are quite a few FTP servers
which will give an error in that case, so you would need to delete
the file first and then rename, destroying the atomicness of the
operation.
(if your FTP even supports it) - what I meant in the above, though
I wasn't clear, was to use /bin/mv on the server, not a rename
through the FTP connection.
Now, I wouldn't want to stir too much oil into the water, but I'm
imagining strange things like, ssh would not have such problems
(assuming you knew that the server was a regular *NIX server and the
server's file system was a system with proper inodes)?
Yes, presuming you ssh in, and then apply the old permissions to the
new file and then do a mv (much like the script Bill ended up
writing), you'd be safe for at least the mainstream unix systems I
would think.
Enjoy,
Peter.
--
<http://www.stairways.com/> <http://download.stairways.com/>
