Rsync can't copy certain files with unusual characters while cp can
 

On my Ubuntu box, I have a mounted windows share connected via gvfs called graphics.

I want to backup everything on a nightly basis from graphics to backupserver/graphics . If I use rsync, it will not copy files that have parent directories with funky characters in them (but the directories themselves will be copied!). Everything else gets rysnced just fine.

So:

graphics/test/•macdir/picture.psd

...when rsynced over to ...

backupserver/graphics/

...gives the error:

rsync: mkstemp "/home/administrator/.gvfs/drobo on x.x.x.x/linux_backups/graphics/test/⢠macdir/.picture.psd" failed: Operation not supported (95)

The directory •macdir gets created but there is nothing in there. This happens for all files underneath dirs with funky names.

The funny thing is cp -Rf works perfectly! Directory and child files all get copied over no matter how strange the characters get in the directory names.

So I assume this is an issue with rsync. Any ideas?

Try add the -s option with rsync, quote from man rsync:

Edit:

You might need the --iconv option? It looks like one of the computers is latin1 and the other is utf-8.

Tried that ( rsync -rauvOs --modify-window=1 ...) and it still didn't work (exact same result).

How would I use that? I added --iconv to my command but got new error:

iconv_open("UTF-8", "...mypath...") failed
rsync error: requested action not supported (code 4) at rsync.c(120) [sender=3.0.7]
administrator@linuxbackups:~/.gvfs/graphics on x.x.x.x$ rsync error: received SIGUSR1 (code 19) at main.c(1306) [sender=3.0.7]

It doesn't support UTF-8? You could try to disable the locale stuff with for example:

LC_ALL=C ; LANG=C ; export LC_ALL LANG

(Before the rsync)

Same error :(

I just had this same problem.
This worked to move the file from windows xp pc to fedora 14 linux:
but this failed to copy it back:
cp also worked as in the original post:
ANSWER:
This made it work on the way back:
You should add the r option for directory contents.


I don't have any explanation, but my guess is a conflict happens with the -a options even when using -co. Unfortunately too, -c slows him down much because of checking the sum.


Here are some other failures with different numbers though:

and this
and this