Bug 4870 - --link-dest results in errors for some paths containing spaces
--link-dest results in errors for some paths containing spaces
Status: RESOLVED WORKSFORME
Product: rsync
Classification: Unclassified
Component: core
2.6.8
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-09 11:16 UTC by David Coppit
Modified: 2009-12-13 00:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Coppit 2007-08-09 11:16:07 UTC
Hi,

I'm somewhat randomly getting errors of this sort:

rsync: stat "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM" (in Backups) failed: No such file or directory (2)
rsync: open "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM/_LastSyncCache" (in Backups): No such file or directory (2)
rsync: recv_generator: mkdir "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM/_Photos & Videos_" (in Backups) failed: No such file or directory (2)
rsync: stat "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM/_Photos & Videos_" (in Backups) failed: No such file or directory (2)
rsync: recv_generator: mkdir "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM/_T-Mobile Hotspots_images_" (in Backups) failed: No such file or directory (2)
rsync: stat "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM/_T-Mobile Hotspots_images_" (in Backups) failed: No such file or directory (2)
rsync: stat "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/SplashPhoto" (in Backups) failed: No such file or directory (2)
rsync: open "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/SplashPhoto/_LastSyncCache" (in Backups): No such file or directory (2)
rsync: stat "/coppit/0/Personal/Taxes/2002/TaxACT Online_files" (in Backups) failed: No such file or directory (2)
rsync: open "/coppit/0/Personal/Taxes/2002/TaxACT Online_files/main_app.css" (in Backups): No such file or directory (2)

If I remove --link-dest, I don't get the errors. Also, the messages all seem to involve paths with spaces in them. It seems like on different runs rsync sometimes succeeds without errors, but perhaps I'm not being very careful about deleting the destination directory between runs.

Here is my setup in detail:

Server: Linux running rsync 2.6.8. (This is an unRAID server.) rsyncd.conf:

gid = root
uid = root
log file = /var/log/resyncd.log

[Backups]
  path = /mnt/disk1/Backups
  comment =
  read only = no
  list = yes

Client: Mac OS X running rsync 2.6.3. (The problem also exists for 2.6.0)

My command line is:

/usr/bin/rsync --archive --force --compress --one-file-system --cvs-exclude --numeric-ids --link-dest=../1 /Users/coppit/Documents/ rsync://root@192.168.1.4/Backups/coppit/0

Let me know if I can provide any more information. I can also upgrade my client if that would help, although upgrading the server will take some interaction with the developer of unRAID.
Comment 1 Wayne Davison 2007-10-14 16:39:14 UTC
In the example you provided, you did not escape the space in the arg that you passed to rsync, so that is an error on your part.  You'll need to either put the arg into quotes, or use a backslash to escape the space.  For a daemon transfer, that will cause the copy to work fine (though in your cited command you are only requesting a file listing, since there is no destination specified).

For a non-daemon transfer, rsync does not try to escape spaces in command-line args that it sends to the server process.  This can lead to a space-splitting problem with the --link-dest arg if the client is the sender.  In 3.0.0 there is now a --protect-args (-s) option that sends the majority of the command-line args across the socket connection, which avoids this space splitting.

I don't wish to add any other space-escaping features to the arg passing, as the type of escaping used depends on what shell is used on the remote system.  I consider the use -s to be the right solution going forward, and the -s option will eventually become the default (when enough time has passed to make 3.0.0 or later the rule rather than the exception).
Comment 2 Matt McCutchen 2007-10-15 21:24:25 UTC
Wayne, what space are you talking about?  I see a basis dir "../1", a source "/Users/coppit/Documents/", and a destination "rsync://root@192.168.1.4/Backups/coppit/0", none of which contains a space.
Comment 3 Wayne Davison 2007-10-15 23:22:18 UTC
Sorry, I thought that the mention of a space was to indicate that the space was in the command-line arg.  Spaces in names read from directories don't make any difference to rsync.
Comment 4 Matt McCutchen 2007-10-15 23:50:50 UTC
Then, something else is going on here, and this report deserves further investigation.
Comment 5 David Coppit 2007-10-16 05:55:43 UTC
I'm the original bug reporter. You guys seem to have misunderstood the problem. The issue is not that there are spaces in the paths specified on the command line. It's that there are spaces in the subdirectories. i.e. My command line specified "rsync://root@192.168.1.4/Backups/coppit/0" and rsync gives an error for "/coppit/0/Palm/Users/David Coppit/SplashPhoto/E75FFB6FBF98B52F/DCIM".

You say, "Spaces in names read from directories don't make any difference to rsync." Do you have any hypothesis as to why spaces seem to result in the errors I am seeing? Perhaps there is some interaction with some other aspect of the system? Let me know if I can do anything to help debug this.
Comment 6 Matt McCutchen 2007-10-18 14:32:27 UTC
(In reply to comment #5)
> Let me know if I can do anything to help debug this.

If at all possible in your configuration, please strace the receiving side and post the resulting log.  This should help us see why the directories that the receiving rsync thinks should exist are missing.
Comment 7 Wayne Davison 2009-12-13 00:07:52 UTC
This has to be some sort of an issue between what rsync is told for the name of a file or dir, and what name must be used to access it.  Rsync just joins the names together with slashes and uses what it is told.  If you have some strace data that shows something that rsync is doing wrong, please let me know.