<font face="courier new,monospace"><br></font><br><div class="gmail_quote">On Fri, May 4, 2012 at 3:14 PM, Indy Singh <span dir="ltr"><<a href="mailto:indy@indigostar.com" target="_blank">indy@indigostar.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While we are on this topic.  One issue I have encountered is that of how to update a 'live' file on a webserver.  Lets say that we have a large file on a webserver 'foo.tar' and I want to replace it with a new version.  If I SFTP upload a replacement file then I am never sure if I am going to mess up someone that may be half way trough downloading the file.<br>


<br>
I just verified that the inode number does not change if I upload a replacement file with SFTP. Would I be correct in thinking that any file downloads that are occurring concurrently with the upload would be corrupted?<br>

</blockquote><div><br>I'd say, potentially YES.<br>
It now becomes a race condition as to whether the write pointer<br>ever passes the read pointer.<br>(Odds are that the local reading would complete before the remote rewrite can.<br> But on NFS'ed or other remoted file systems... you mileage may vary.)<br>

<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would it be safe to upload the new file as 'new.tar' then use the commands 'rm foo.tar' followed by 'mv new.tar foo.tar'?  On the assumption that the rm command would only unlink the directory entry but any current file handles being used to download the file would continue to work.  Any new downloads would use the new file.</blockquote>

<div><br>Yup.<br> <br></div></div><br>