Hacker News Reader

Comment by bigbubba | Hacker News Reader

> rsync is not a replacement [...] I can't use cp like syntax, it's not a replacement.

Can you explain what you mean by this? I use rsync with the 'same syntax'; instead of 'scp src user@remote:/dst' I can do 'rsync src user@remote:/dst'

View on HN

Handling of directories and their contents (trailing slashes) is different.

That tab completion will really get you sometimes :)

Rsync has weird syntax, I have accidentally copied contents of dirs instead of the dir

Rsync has "weird" syntax for a reason. Unlike other unix-like commands, it treats trailing slashes as significant. If a directory has a trailing slash, it means "contents" of the directory". No slash means "the directory itself". These are two different concepts, and a program that copies directories should take the difference into account.

scp (and cp, for that matter) don't take this difference into account. That leads to gotchas with recursive (-r) copying. Most importantly, scp isn't idemopotent:

scp -r fromdir todir

If todir doesn't exist, scp will copy the contents of directory fromdir to a new directory named todir.

Execute the same command again (now that todir exists), and scp will copy fromdir to todir/fromdir .

On the other hand:

rsync -a fromdir/ todir

will always copy the contents of fromdir into a directory named todir (effectively, a directory rename operation), whether todir exists or not.

rsync -a fromdir todir

will always copy the directory fromdir into the directory todir, whether todir exists or not.

These rsync operations are idempotent, which it important because rsync is designed to incrementally re-sync directories. It is expected that it will commonly be run more than once, which is why it needed to address this IMHO fundamental bug/limitation in cp and scp.

Thanks for the concise clarification! I always was too lazy to think and did trial and error until it did the thing I intended :)

What does rsync'ing "the directory itself" (in contrast to the directory content) even do? A mkdir? Does it even need to use the network connection?

Rsync only works on directories in recursive mode which also copies the contents

"Rsyncing the directory itself" means making a copy of the directory node (the root of the tree) and naming it with the original name in the new location. That is different than taking the children of the source directory and copying them into the new location.

Scp and cp have the same semantics, so cp is vulberable to this gotcha as well. Rsync doesn't have to be used with remote sources or targets (nor does scp).

> so cp is vulberable to this gotcha as well

This is in fact why use rsync for local copies as well, it's much more consistent.

Ah, good explanation. Rsync's command line syntax always felt more intuitive to me, and it being idempotent is part of that.

Yeah I don’t quite understand that stance either. It seems like a great replacement. Rsync > scp in my opinion. I have always reached for it first.

Scp works fine in gitbash, I’ve never found a windows-native rsync.

I never had a problem with cygwin rsync.

It sees the filesystem the way Cygwin maps it, so what's transferred isn't an exact match for Windows files and attributes.

For example, Windows symlinks and Cygwin symlinks are quite different. I don't think Cygwin rsync can replicate a directory containing Windows symlinks properly, so that the replica behaves the same as seen by Windows programs.

I'm not sure about the other Windows attributes such as ACLs but I would be surprised if Cygwin rsync can replicate those.

very few things can handle stuff like that going from windows->$another_os. You'll just have to compress them down with a format that understands those and preserves them and transfer it. Some of them don't even make sense on other filesystems.

That's true. But sometimes you just want to move things from Windows to Windows. Then cygwin rsync isn't up to it. (scp isn't either.)

That's different from MacOS, where there's a Mac-native version of rsync to transfer attributes that don't exist on $another_os.

rsync has a very restrictive licence.

As a user-facing program it literally doesn't matter, it's only a political issue. You install it and you use it. The problem is if you're scared of the presence of GPLv3 for no reason.

It means that for example Mac OS or Windows will not bundle it by default.

Because they are scared of the presence of GPLv3 for no reason. Still a good point. Mac OS also doesn't ship modern GCC or Bash, so they are pretty much at war with reality at this point - or rather - creating their own ecosystem.

every other unix system besides linux used to be like that. for many sysadmins the first action on a new unix server or workstation was to install gnu tools.

apple decided to include those tools by default possibly in order to attract users. then they decided to stop updating and now macos is no better than those other unix systems used to be.

i used a mac for a few years and i don't miss the experience. gnu/linux just works

I think that problem is with macOS & Windows, not with rsync. There is no real reason why either cannot bundle it; they just choose not to.

There is openrsync if you don't like the rsync license.

https://www.openrsync.org/

Reply on news.ycombinator.com