Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
L
liblongpath-rsync
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
liblongpath
liblongpath-rsync
Commits
0758b2db
Commit
0758b2db
authored
Sep 22, 2007
by
Wayne Davison
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Document the change to how --releative works.
parent
74db1f14
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
23 additions
and
16 deletions
+23
-16
rsync.yo
rsync.yo
+23
-16
No files found.
rsync.yo
View file @
0758b2db
...
...
@@ -601,10 +601,23 @@ machine. If instead you used
quote(tt( rsync -avR /foo/bar/baz.c remote:/tmp/))
then a file named /tmp/foo/bar/baz.c would be created on the remote
machine -- the full path name is preserved. To limit the amount of
path information that is sent, you have a couple options: (1) With
a modern rsync on the sending side (beginning with 2.6.7), you can
insert a dot and a slash into the source path, like this:
machine, preserving its full path. These extra path elements are called
"implied directories" (i.e. the "foo" and the "foo/bar" directories in the
above example).
Beginning with rsync 3.0.0, rsync always sends these implied directories as
real directories in the file list, even if a path element is really a
symlink on the sending side. This prevents some really unexpected
behaviors when copying the full path of a file that you didn't realize had
a symlink in its path. If you want to duplicate a server-side symlink,
include both the symlink via its path, and referent directory via its real
path. If you're dealing with an older rsync on the sending side, you may
need to use the bf(--no-implied-dirs) option.
It is also possible to limit the amount of path information that is sent as
implied directories for each path you specify. With a modern rsync on the
sending side (beginning with 2.6.7), you can insert a dot and a slash into
the source path, like this:
quote(tt( rsync -avR /foo/./bar/baz.c remote:/tmp/))
...
...
@@ -617,8 +630,8 @@ quote(tt( (cd /foo; rsync -avR bar/baz.c remote:/tmp/) ))
(Note that the parens put the two commands into a sub-shell, so that the
"cd" command doesn't remain in effect for future commands.)
If you're pulling files
, use this idiom (which doesn't work with an
rsync daemon
):
If you're pulling files
from an older rsync, use this idiom (but only
for a non-daemon transfer
):
quote(
tt( rsync -avR --rsync-path="cd /foo; rsync" \ )nl()
...
...
@@ -632,7 +645,7 @@ means that the corresponding path elements on the destination system are
left unchanged if they exist, and any missing implied directories are
created with default attributes. This even allows these implied path
elements to have big differences, such as being a symlink to a directory on
one side of the transfer, and a real directory on the other
side.
the receiving
side.
For instance, if a command-line arg or a files-from entry told rsync to
transfer the file "path/foo/file", the directories "path" and "path/foo"
...
...
@@ -645,15 +658,9 @@ ends up being created in "path/bar". Another way to accomplish this link
preservation is to use the bf(--keep-dirlinks) option (which will also
affect symlinks to directories in the rest of the transfer).
In a similar but opposite scenario, if the transfer of "path/foo/file" is
requested and "path/foo" is a symlink on the sending side, running without
bf(--no-implied-dirs) would cause rsync to transform "path/foo" on the
receiving side into an identical symlink, and then attempt to transfer
"path/foo/file", which might fail if the duplicated symlink did not point
to a directory on the receiving side. Another way to avoid this sending of
a symlink as an implied directory is to use bf(--copy-unsafe-links), or
bf(--copy-dirlinks) (both of which also affect symlinks in the rest of the
transfer -- see their descriptions for full details).
When pulling files from an rsync older than 3.0.0, you may need to use this
option if the sending side has a symlink in the path you request and you
wish the implied directories to be transferred as normal directories.
dit(bf(-b, --backup)) With this option, preexisting destination files are
renamed as each file is transferred or deleted. You can control where the
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment