Bug#313044: /usr/bin/scp: scp: Atomic transfers?
merge 313044 313045
thanks
On Sat, Jun 11, 2005 at 02:19:22PM +0200, Olaf van der Spek wrote:
> When you transfer a file via scp, it appears the old file is truncated and then written when bytes arrive.
> This means the file is unusable while the transfer is in progress and this is undesired for certain types of files.
> Also, if the transfer is aborted the file is left in an invalid state.
> Would it be possible to make transfers atomic?
>
> Advantages:
> File remains valid during transfer.
> File remains valid when transfer is aborted.
To be honest, I doubt this will be implemented in scp. As
http://www.openssh.org/faq.html#2.10 says:
2.10 - Will you add [foo] to scp?
Short Answer: no.
Long Answer: scp is not standardized. The closest thing it has to a
specification is "what rcp does". Since the same command is used on
both ends of the connection, adding features or options risks breaking
interoperability with other implementations.
New features are more likely in sftp, since the protocol is
standardized (well, a draft standard), extensible, and the client and
server are decoupled.
That said, I suppose it would be possible to implement this such that it
didn't break interoperability, so I'll leave the bug open.
It would be fairly straightforward to write a script on top of scp (or
sftp, for that matter) that does atomic transfers by 'scp ...' followed
by 'ssh mv ...'. The only fiddly bit would be doing the command-line
parsing.
> When you upload a file while the destination file is in-use, you get the Text file busy error.
> Could this be avoided?
> I'd guess either by trying an unlink when you get that error or by the atomic transfers feature request.
I think the only sane way to implement that would be by copying then
atomically renaming, so I've merged the two bugs.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: