there is no 'move' equivalent for scp

[Joolz]

Binary package hint: openssh-client

something like 'smv' (secure move) would be very useful to me. A little bash function would solve it but imho this would better be a part of scp (-u ?)

[Martijn vdS (martijn)]

You can already use 'rsync --remove-source-files'

[Joolz (joolz)]

FYI http://kleber.net/ssh/ssh-faq-4.html

[Colin Watson (cjwatson)]

The cited FAQ only applies to commercial SSH ...

I think this is more likely to get done on top of sftp, to be honest.

[Loye Young (loyeyoung)]

The requested functionality exists.

Either (i) log into the remote machine via ssh and execute a mv command or (ii) mount the remote director{y|ies} to a local mountpoint using sshfs and then use mv as normal.

However, before closing this bug, the technique should probably be documented in the ssh man page.

[Colin Watson (cjwatson)]

With regard to (i), the more usual case where I find myself needing this is a remote-to-local or local-to-remote move, not a remote-to-remote move, and I agree that an interface similar to scp would be convenient. That's why I haven't closed this.

(ii) is a valid point, but I'd like openssh to be useful standalone, not just when augmented with sshfs. Not all users can use sshfs, for example if they aren't in the fuse group on the system in question. I am frequently in this position on company machines, for instance.

[Loye Young (loyeyoung)]

(i) Right. My bad. I wrote mv but meant sftp

(ii) Reasonable minds can differ on this one, but I still think you are better off in that case using scp or sftp and deleting afterwards. A "mv" is essentially: load to memory; write to destination; delete from origination; release memory. I'd be hesitant to do an automatic, transparent, immediate, remote delete over the wire. The server may have sent the file out the ethernet port, but that's no guarantee the client received and properly wrote the file. If you have mounted the remote file system under fuse, you would at least have fusefs to help ensure it all got done right. (Handling the reading, writing, and verifying of files a lot of what file systems are supposed to do.)

Thought: You could make ssh run an md5 hash at both ends to ensure everything was ducky before deleting the remote file. Of course, that would require rewriting both the client and the server.

For upstream's view, see http://www.openssh.com/faq.html#2.10

Loye Young

[Colin Watson (cjwatson)]

To be perfectly blunt, I'm the package maintainer and I would argue that I have a pretty good view of what users tend to need.

Both scp and sftp protocols are perfectly capable of ensuring that the remote end has written the file before returning success; they're lockstep protocols, not fire-and-forget. fuse offers no reliability improvement here.

The upstream FAQ entry in question would not apply if scp were rewritten to use the sftp protocol behind the scenes, which I'm planning to work on.