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.
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).
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.
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.
Then, something else is going on here, and this report deserves further investigation.
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.
(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.
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.