OpenSSH 8.0 released [LWN.net]

OpenSSH 8.0 released

Posted Apr 20, 2019 7:16 UTC (Sat) by marcH (subscriber, #57642)
In reply to: OpenSSH 8.0 released by marcH
Parent article: OpenSSH 8.0 released

Just remembered one of the reasons I stopped using "cp -r". Assuming dst/ doesn't exist yet, then running this twice:

cp -r src/ dst/
cp -r src/ dst/

... does something different the second time on Linux (not on macOS).

Running the same rsync command twice never does something different the second time, that's crazy.

to post comments

OpenSSH 8.0 released

Posted Apr 20, 2019 11:06 UTC (Sat) by dw (subscriber, #12017) [Link] (5 responses)

I'm not sure that's true. Some combination of 'with slash' or 'without slash' on either the source or dest changes behaviour if the target already exists as a directory. I never stop to figure out what went wrong, so can't be more specific than "something to do with slashes". I hate this aspect of rsync's UI

OpenSSH 8.0 released

Posted Apr 20, 2019 17:47 UTC (Sat) by marcH (subscriber, #57642) [Link]

> I'm not sure that's true

Why didn't you just try it? It's not like this requires a complex setup.

Yes, a trailing slash "src/" in the rsync source means "src/*". It's not the most intuitive syntax but it's a useful feature.

That wasn't the point though, the point was: run the same "cp -r" command twice and it can give different results the second time on Linux. Run the same command on macOS and it can behave differently again. None of that craziness with rsync.

OpenSSH 8.0 released

Posted Apr 20, 2019 22:11 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (3 responses)

So first of all, I don't think a slash on the destination ever matters.

A slash on the source directory does change rsync's behaviour, but that has nothing to do with whether the destination exists. The behaviours are orthogonal, here is a matrix:

when dst doesn't exist
rsync -a src/ dst --> creates dst, copies contents of src into dst
rsync -a src dst --> creates dst, copies src into dst

when dst exists
rsync -a src/ dst --> copies contents of src into dst
rsync -a src dst --> copies src into dst

I do remember being surprised by this when I first used rsync, but the man page is fairly clear about it; I'm curious to hear if what behaviour you might find less surprising, while retaining the ability to copy either a directory or its contents (without using shell wildcards or the like)?

OpenSSH 8.0 released

Posted Apr 22, 2019 9:12 UTC (Mon) by oldtomas (guest, #72579) [Link]

Quoth the man page:

"A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning 'copy the contents of this directory' as opposed to 'copy the directory by name', but in both cases the attributes of the containing directory are transferred to the containing directory on the destination"

(And for the reverse: just searching for "trailing" or "trailing slash" clears that part up pretty quickly).

Rsync's man page may be daunting, but it is extremely well written.

"If all else fails, read the instructions"

rsync mnemonic

Posted Apr 26, 2019 21:43 UTC (Fri) by naptastic (guest, #60139) [Link] (1 responses)

The choice seemed arbitrary to me until I came up with a mnemonic for it: Trailing slash means "the contents of the directory," and no trailing slash means "the directory as a single thing." Somehow my brain also maps that to pointers versus values:

rsync(src, dest);  /* one item, named 'src', will be created in dest */
rsync(*src, dest); /* everything under 'src' will be created in dest */

I don't know if that helps or even makes sense to anyone else.

rsync mnemonic

Posted Apr 26, 2019 23:49 UTC (Fri) by karkhaz (subscriber, #99844) [Link]

That's a beautiful analogy :-)

OpenSSH 8.0 released

Posted Apr 22, 2019 22:09 UTC (Mon) by Pc5Y9sbv (guest, #41328) [Link]

Along the same lines, I eventually started using the -R (--relative) flag to rsync in my most confident idempotent transfer mode:

rsync -avRP host:/prefix1/./rel1 host:/prefix2/./rel2 /prefix3/.

This creates /prefix3/rel1 and /prefix3/rel2 hierarchies with the easy to understand semantics that it splices the trees at the '.' point. Also, for me the --excludes/--includes patterns are easier to understand when I know they will be rooted at the '.' as well.