name too long problem?

[Carlos Carvalho]

Benjamin R. Haskell (rsync at benizi.com) wrote on 15 February 2012 09:46:
 >On Wed, 15 Feb 2012, Carlos Carvalho wrote:
 >
 >> In the latest 3.1 I get this in our backup:
 >>
 >> filename overflows max-path len by 1: <path>
 >> filename overflows max-path len by 1: <path>
 >> filename overflows max-path len by 9: <path>
 >> filename overflows max-path len by 7: <path>
 >> filename overflows max-path len by 4: <path>
 >> filename overflows max-path len by 5: <path>
 >> filename overflows max-path len by 6: <path>
 >>
 >> Both sender and receiver are linux machines, so the max-path is the 
 >> same. Locale/lang are both set to C and --no-iconv is used. How can a 
 >> name overflow in the receiver but exist in the sender? Can it be due 
 >> to the temporary extension?
 >
 >Presumably, you're not syncing from root to root.  So:
 >
 >Files on sender:
 >/this/is/some/long/path # assume it's max-path length
 >
 >rsync -R /./this/is/some/long/path remote:/backups/
 >
 >Then, on the receiver, this path len is way too long:
 >/backups/this/is/some/long/path
 >
 >One way to fix that would be to sync to a shorter prefix.  (mv /backups 
 >/b).

On the receiver, which starts the process, I cd /to/path and then do
rsync options origin:from/ ./
Therefore there are no prefixes on the receiver.

Could these messages be from the sender? If so, is there a trick with
--rsh to cd to the path in the sender before launching rsync there?
This is what happens when connecting to a daemon but for backups we
use ssh.

If it's necessary to use "DAEMON FEATURES VIA A REMOTE-SHELL
CONNECTION" will it do the chroot (it'll run as root)?