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?
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). -- Best, Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems possible that it is the temporary file name. That would be easy to test. Find the longest filename (or any that fails) and attempt to touch a file with the temporary name that rsync would use. If that is the problem then --inplace would be a workaround. On 02/15/12 09:21, 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?- -- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. Kevin at FutureQuest.net (work) Orlando, Florida kmk at sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk88EZsACgkQVKC1jlbQAQeiJQCeJfkps3CIMPW47iHlggSEYZLu qqkAnjP103y9JgVauKwftlIIjUP44mZE =nBdg -----END PGP SIGNATURE-----
On Wed, Feb 15, 2012 at 6:21 AM, Carlos Carvalho <carlos at fisica.ufpr.br>wrote:> filename overflows max-path len by 1: <path> >Count the characters in the displayed <path> and you'll see what the max_path value is. That message is output by the sender, and indicates names that are too long to put into the stream of file-list data. Since rsync currently uses paths from a single chdir, you cannot send files that overflow the OS's max-path limit when referenced by the in-transfer path + filename. ..wayne.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20120216/98d6278d/attachment.html>