[tpm] more problems than solutions this week

[Tom Legrady]

On Unix, if you "rm file1" or "mv file2 file1", file1 goes away, but if
someone has it open, they maintain a link to an "invisible file". The file
only REALLY goes away when they close their filehandle.

On Windows, my understanding is that you can't delete files that are open,
but i don't deal with Windows.

Tom

On Fri, May 4, 2012 at 3:14 PM, Indy Singh <indy at indigostar.com> wrote:

> 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.
>
> 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?
>
> 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.
>
>
>
> Indy Singh
> IndigoSTAR Software -- www.indigostar.com
> -----Original Message----- From: arocker at Vex.Net
> Sent: Friday, May 04, 2012 2:44 PM
> To: TPM
> Subject: Re: [tpm] more problems than solutions this week
>
>
>
> I see Indy's answered your problem, but just a point on the topic:
>
>  But what I've found is that the inode doesn't change!
>> [so I'd assume that the ">" redirection simply rewinds
>> the write pointer to offset zero and writes the string
>> and then truncates the file at that point.]
>>
>>
> That's why "sort file > file" (and similar commands) is fatal; it resets
> the pointer on the (output) file, then starts trying to read from the
> (input) file, whose pointer now says it's at EOF.
>
> ______________________________**_________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/**listinfo/toronto-pm<http://mail.pm.org/mailman/listinfo/toronto-pm>
> ______________________________**_________________
> toronto-pm mailing list
> toronto-pm at pm.org
> http://mail.pm.org/mailman/**listinfo/toronto-pm<http://mail.pm.org/mailman/listinfo/toronto-pm>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/toronto-pm/attachments/20120504/f0bbbc6c/attachment-0001.html>