Comment by Izkata | Hacker News Reader

Comment by Izkata | Hacker News Reader

Parent Full thread

> Because such cases are so rare, it does not make any difference for me if I have to add "/*" instead of the slightly shorter "/" (even when I also have to add "/.*" for hidden files/directories).

I think this is the wrong way to think of it. It's more like "rsync foo/ bar/" means "make these two directories the same" - it does change the last-modified timestamp on bar/ to match foo/. If you use "foo/*" it excludes the directory and last-modified becomes now.

For all the combinations this is what's in my head, and I find it for the most part very consistent and predictable:

* rsync -a foo bar/ -> put this file in this directory (a directory is a special type of file, so you end up with bar/foo/)

* rsync -a foo/ bar/ -> put the contents of foo/ into bar/ (but also we're syncing the directories, which is why bar/'s last-modified is changed)

* rsync -a foo bar -> put this file in here, whatever "bar" is (makes a file named bar, unless foo is a directory - you can't put a directory inside a non-directory file, so it makes directory bar and puts foo inside it)

* rsync -a foo/ bar -> This is the only one I have issues with because it doesn't particularly make sense so I never have reason to even try using it - put a directory into a file? But it's the same as "foo/ bar/" case.

> If you use "foo/*" it excludes the directory and last-modified becomes now.

True, but instead of adding "/" to the source you obtain the same effect by deleting the last component of the destination (which is normally a non-action, you just do not auto-complete far enough).

If you meant that you might want to have "foo" and "bar" directories with the same content and timestamps, but with different names, you can rename the target directory before and after the rsync.

This is negligible overhead, because in many decades of using computers for all kinds of applications, I have not encountered a single case when I would have needed to have 2 directories with identical content and even with identical directory timestamps, but with different directory names.

Making a backup directory in the same directory with the original directory would not be a good example, that would be just stupid. Any backup directory should be placed as far as possible from the original directory, when not on a different filesystem, in which case they can have the same name.

The way how rsync handles names without trailing slashes is completely right.

The way how rsync handles trailing slashes to encode alternative behaviors might have been OK if this feature would not have been in conflict with the auto-complete feature of the shells.

For all the rsync behaviors that can be obtained by adding some "/", there are alternatives almost as simple as that.

A slight simplification in the encoding of the seldom used alternative behaviors is paid by a large complication in the typing of the frequently used behaviors, where you must always insert a backspace + space sequence after each directory name, to delete the dangerous trailing slash.

> you can rename the target directory before and after the rsync.

The problem is that the ergonomics of renaming a directory on a remote machine is vastly inferior to doing so on a local machine. Locally, you can use mv. There is no "rmv".

Even worse, rsync is from a different generation of unix utilities than cp/mv or rcp/rsh or scp/ssh. It is more "Swiss army knife" style, able to stand on its own. It shouldn't need to depend on a mythical rmv command.

Finally, I very frequently use the "copy a directory to a new name" feature, both locally and remotely. Locally, I use it to make a quick backup of a directory for emergency recovery. Remotely, syncing a local log directory to a remote "log.machine-name" is pretty common I think. Without renaming, you would do "log -> remote:machine-name", but machine-name would have to exist on the remote machine, necessitating a separate "rmkdir" command.

Reply on news.ycombinator.com