exactly. the sending side knows when its done, but not the receiving side.
and many systems have a receiving directory,
often called a loading dock, where someone scans for new files,
and they can't tell between a complete file or a partial file.

rsync's solution is fine, in that it disguises the new name until an atomic 
move.
scp would too IF ONLY they changed the file's mode (for example)
to zero (or somesuch) until the copy was done. its hard to see
how that would break existing "compatibility" with rcp, but what do i know?

thanks for all teh replies.

On May 4, 2011, at 8:05 PM, Edward Ned Harvey wrote:

> I'm sorry, I don't see the problem.
>  
> You mean you have scp transferring a file, and outside of scp you have some 
> 3rd party tool constantly polling the existence of the file to see if it's 
> there and if it's completed yet?
>  
> I would normally say "Wait for scp to finish.  When scp exits then you know 
> it finished." ... I can't think of any reason that would be unreasonable, 
> except if you have a 3rd application polling as described above...
>  
>  
>  
> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] On 
> Behalf Of Andrew Hume
> Sent: Wednesday, May 04, 2011 6:54 PM
> To: LOPSA Technical Discussions
> Subject: [lopsa-tech] scp
>  
> it is time for my annual head-slapping over scp.
>  
> is there any plausible alternative to scp? mostly its all fine,
> but i am struggling over having to do an additional ssh
> afterwards to confirm teh file got there (or to let
> the other side know its done).
>  
> any reasonable command would do something with the file modes
> or (like ftp) allow you to rename the file (say from foo! to foo) after the 
> copy finished.
> of course, the wretched scp faq says "no changes; it has to be like rcp"
> which is fine and all, except rcp is a very old piece of crap.
>  
> surely we can do better?
> 
> ------------------
> Andrew Hume  (best -> Telework) +1 623-551-2845
> and...@research.att.com  (Work) +1 973-236-2014
> AT&T Labs - Research; member of USENIX and LOPSA
>  
> 
> 
>  


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
and...@research.att.com  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




_______________________________________________
Tech mailing list
Tech@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to