rsyncing from a remote machine to a relatively local smbfs partition, I notice that files that contain colons or question marks fail to get created, although rsync does take the time to download them (into the bit bucket, one presumes). Quoting from a real rsync session: At the same time, there's a corresponding message from the kernel in kern.log:
[ note: I'm not the maintainer ] The bit bucket part is unfortunately not possible to avoid with the current rsync protocol, once the files are selected the sending side simply sends... The problem isn't that rsync fails to detect a failed mkstemp() here, but that you're trying to copy files with names that aren't supported by the receiving filesystem; the question mark can't be used on an SMB (nor VFAT) filesystem. There isn't really anything that can be done about this, I'm afraid... How would you suggest that rsync should cope with such a situation? One possible workaround would be a "--sanitize-filenames" option (better suggestions welcome :-). This would make rsync replace all dubious characters in filenames to an underscore or something. However, that would just be working around the problem of crippled filesystems. Paul Slootman
I knew the root cause was a braindamaged FS, but I was kind of hoping for rsync to work around it, in the spirit of portability. I'm sure there are filesystems that happily allow forward-slashes in filenames too. :) I could suggest an option indicating exactly which characters to munge (eg. URLencode ;) on the target system. Mind you I haven't really thought the idea through all that thoroughly, so perhaps someone else will (eventually) come up with something better...
unmerge 151568 retitle 151568 Avoid wastefully transmitting file data when mkstemp() fails thanks I think this is a valid enhancement request separate from the issue with illegal characters tracked in bug 161115. [I have no affiliation with Debian, but I work on the upstream rsync. Feel free to flame me if I'm taking too much liberty manipulating Debian bugs.]