3 ms·

rsync is a perfect superset of scp feature wise. It also has a much better protocol design. For your daily use it is almost syntax compatible too.

cat199 6y ago
> almost syntax compatible except the 'almost' can blow away filesystems if not used correctly (trailing slash vs no trailing slash being context dependent on presence/absence of remote files).. no idea why rync used differnt path semantics - cpdup for example uses identical semantics for a similar (but less performant) utility
- stjohnswarts 6y ago
  exactly. I always do dry runs on folders and files to makes sure it's not going to blow away something. Scp is nice and simple and close enough to what I need 95% of the time. I only use rsync when I need a sledgehammer
dahart 6y ago
What are the command line flags that mimic scp’s default behavior? I shouldn’t use the defaults, with no command line flags, should I? I keep reading through the man page trying to figure that out, but the options are numerous and confusing. I love using rsync but the interface is what gets in the way compared to scp. There are too many different rsync workflows that are all given equal weight in the documentation.
- xorcist 6y ago
  Basic syntax, "options source destination", is similar enough. scp file.bin server: rsync file.bin server: The obvious difference is that rsync defaults to a more unixy no-news-is-good-news output, it will only output errors. To show interactive progress use rsync -vP file.bin server: Use "-e" to set ssh options, just like with scp. Use "-r" to transfer whole directories, just like with scp. But you're likely to use "-a" with rsync instead which is recursive preserving all attributes and timestamps. Another difference is that rsync will resume transfers, which scp can't. It can do sparse transfers reasonably well. It also has more sane security defaults And, as implied by the name, update a remote directory including deletions. Check out "man rsync" for the full story. It's not long after your shell and editor in daily usefulness.
  - stinos 6y ago
    Use "-e" to set ssh options, just like with scp On my rsync -e sets the executable, and my scp doesn't have -e but -o. Even then it's a bit of a stretch (or I'm missing something); e.g. for the ssh option I use mst of the time, a non-default port: scp -P 4222 is equivalent to scp -o"Port=4222" is equivalent to rsync -e "ssh -p 4222" Again, this is just what I use after having to look it up at one point so I might be missing something, but it's not like the arguments translate one to one?
    - xorcist 6y ago
      Good catch! I was too sure to check. scp doesn't take -e.
- adrian_b 6y ago
  I do not believe that it is a desirable target to mimic the default behavior of scp. I my opinion, the default behavior of any file copy program must be to make exact copies of the sources. I find it very annoying that all UNIX copying programs do not have this behavior and by default they will lose information. Therefore I always use aliases for all copying commands (cp, scp, rsync etc.), so that by default they will make exact copies. For example, to make exact copies rsync needs "--archive --xattrs --acls", and cp needs "--no-dereference --recursive --preserve=all". cp also needs to be compiled with enabled extended attributes, which many Linux distributions disable, otherwise you lose the extended attributes without any warning or error. Another trap on Linux, which may prevent making exact file copies, is when tmpfs is used for /tmp and some file is copied through /tmp, e.g. for passing it to another user. A copy through tmpfs may lose extended attributes and it also may truncate the timestamps of some file systems.

cat199 6y ago

> almost syntax compatible except the 'almost' can blow away filesystems if not used correctly (trailing slash vs no trailing slash being context dependent on presence/absence of remote files).. no idea why rync used differnt path semantics - cpdup for example uses identical semantics for a similar (but less performant) utility

stjohnswarts 6y ago
exactly. I always do dry runs on folders and files to makes sure it's not going to blow away something. Scp is nice and simple and close enough to what I need 95% of the time. I only use rsync when I need a sledgehammer

dahart 6y ago

What are the command line flags that mimic scp’s default behavior? I shouldn’t use the defaults, with no command line flags, should I? I keep reading through the man page trying to figure that out, but the options are numerous and confusing. I love using rsync but the interface is what gets in the way compared to scp. There are too many different rsync workflows that are all given equal weight in the documentation.

xorcist 6y ago
Basic syntax, "options source destination", is similar enough. scp file.bin server: rsync file.bin server: The obvious difference is that rsync defaults to a more unixy no-news-is-good-news output, it will only output errors. To show interactive progress use rsync -vP file.bin server: Use "-e" to set ssh options, just like with scp. Use "-r" to transfer whole directories, just like with scp. But you're likely to use "-a" with rsync instead which is recursive preserving all attributes and timestamps. Another difference is that rsync will resume transfers, which scp can't. It can do sparse transfers reasonably well. It also has more sane security defaults And, as implied by the name, update a remote directory including deletions. Check out "man rsync" for the full story. It's not long after your shell and editor in daily usefulness.
- stinos 6y ago
  Use "-e" to set ssh options, just like with scp On my rsync -e sets the executable, and my scp doesn't have -e but -o. Even then it's a bit of a stretch (or I'm missing something); e.g. for the ssh option I use mst of the time, a non-default port: scp -P 4222 is equivalent to scp -o"Port=4222" is equivalent to rsync -e "ssh -p 4222" Again, this is just what I use after having to look it up at one point so I might be missing something, but it's not like the arguments translate one to one?
  - xorcist 6y ago
    Good catch! I was too sure to check. scp doesn't take -e.
adrian_b 6y ago
I do not believe that it is a desirable target to mimic the default behavior of scp. I my opinion, the default behavior of any file copy program must be to make exact copies of the sources. I find it very annoying that all UNIX copying programs do not have this behavior and by default they will lose information. Therefore I always use aliases for all copying commands (cp, scp, rsync etc.), so that by default they will make exact copies. For example, to make exact copies rsync needs "--archive --xattrs --acls", and cp needs "--no-dereference --recursive --preserve=all". cp also needs to be compiled with enabled extended attributes, which many Linux distributions disable, otherwise you lose the extended attributes without any warning or error. Another trap on Linux, which may prevent making exact file copies, is when tmpfs is used for /tmp and some file is copied through /tmp, e.g. for passing it to another user. A copy through tmpfs may lose extended attributes and it also may truncate the timestamps of some file systems.