Skip to main content

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
Asked
Modified 3 months ago
Viewed 492 times
6

Suppose I want to sync the contents of a directory (source_dir) using rsync without creating a directory named source_dir in the target directory.

I can do this using rsync source_dir/ target_dir or rsync source_dir/* target_dir.

Is the following correct? The former will sync everything, including hidden files and source_dir/.. Using the latter the shell will expand the * to every every non-hidden file in source_dir and thus every non-hidden file in source_dir will be synced.

(I'm asking mainly to check my understanding, but the XY problem behind this is that rsync -t source_dir/ target_dir tries to set the time and I want to avoid that without using -O.)

1 Answer 1

13

You are correct.

If you're using a shell such as bash you can tell it to have * match on dot files as well as usual ones:

shopt -s dotglob
rsync -rt source_dir/* target_dir/

I've added a trailing slash to the target so that it's always considered as a directory - even if the wildcard expands only to a single item. At the other end of the scale, you may encounter problems with the shell enumerating the results if * matches a (very) large number of files.

Possibly a better solution would be use find to generate the set of files, having it exclude the root of the directory tree:

find source_dir -mindepth 1 -print0 |
    rsync -t --files-from=- --from0 . target-dir/

(If source_dir is an absolute path then replace the . with /.)

7
  • 2
    It's worth mentioning that expanding the * will have arg issues for large expansions, but that's a shell issue rather than an rysnc issue, per se.
    bxm
    –  bxm
    2025-07-07 10:42:11 +00:00
    Commented Jul 7 at 10:42
  • @bxm is that still a thing? I've updated my answer to caution against it but I can't say I've noticed an issue recently. Also see a definitive "probably not!" at Is there a maximum to bash file name expansion (globbing) and if so, what is it
    Chris Davies
    –  Chris Davies
    2025-07-07 10:50:22 +00:00
    Commented Jul 7 at 10:50
  • 1
    I ... I assume it is ... either that or I've been using xargs like a chump for the past several years.
    bxm
    –  bxm
    2025-07-07 10:52:01 +00:00
    Commented Jul 7 at 10:52
  • 1
    OK I feel vindicated: bash: /opt/homebrew/opt/coreutils/libexec/gnubin/cat: Argument list too long.
    bxm
    –  bxm
    2025-07-07 11:09:06 +00:00
    Commented Jul 7 at 11:09
  • 3
    The limit of the size of the argument list (and the size of the environment) is still a thing. You may not bump into it too often on Linux, because the limit is quite high, but there is certainly still a limit (that does not exist for shell built-ins). Other Unixes may have lower limits than Linux, too, and the question never mentions what Unix is in use.
    Kusalananda
    –  Kusalananda
    2025-07-07 12:09:23 +00:00
    Commented Jul 7 at 12:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.

Morty Proxy This is a proxified and sanitized view of the page, visit original site.