Benjamin R. Haskell (rs...@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)? -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
