Re: name too long problem?
On Wed, Feb 15, 2012 at 6:21 AM, Carlos Carvalho wrote: > filename overflows max-path len by 1: > Count the characters in the displayed 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.. -- 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
Re: name too long problem?
Kevin Korb (k...@sanitarium.net) wrote on 15 February 2012 15:12: >It seems possible that it is the temporary file name. Yes. After sending the other message I noticed that the amounts rsync lists as exceeding max-path cannot be explained by a prefix at the sender: Carlos Carvalho (car...@fisica.ufpr.br) wrote on 15 February 2012 18:09: >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: > >> filename overflows max-path len by 1: > >> filename overflows max-path len by 9: > >> filename overflows max-path len by 7: > >> filename overflows max-path len by 4: > >> filename overflows max-path len by 5: > >> filename overflows max-path len by 6: The sender prefix in this case is 7 chars long, so it cannot explain two of the overflows above. In this case I think rsync could reduce the temporary name to fit in max-path. I thought Wayne had put a patch about something similar but I don't remember the details (maybe there was something related to wide chars). >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. It doesn't say which tempname it'd use, just the filename that failed. >If that is the problem then --inplace would be a workaround. It didn't work here. Besides, there are may situations where it cannot be used, so if rsync could avoid the problem it'd be better. Another possibility is to set temp-dir to a shorter path than the file. I put it to the root of the tree but it also didn't work. -- 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
Re: name too long problem?
-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: filename overflows > max-path len by 1: filename overflows max-path len by 9: > filename overflows max-path len by 7: filename > overflows max-path len by 4: filename overflows max-path len > by 5: filename overflows max-path len by 6: > > 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. ke...@futurequest.net (work) Orlando, Floridak...@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- -- 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
Re: name too long problem?
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: >> filename overflows max-path len by 1: >> filename overflows max-path len by 9: >> filename overflows max-path len by 7: >> filename overflows max-path len by 4: >> filename overflows max-path len by 5: >> filename overflows max-path len by 6: >> >> 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
Re: name too long problem?
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: filename overflows max-path len by 1: filename overflows max-path len by 9: filename overflows max-path len by 7: filename overflows max-path len by 4: filename overflows max-path len by 5: filename overflows max-path len by 6: 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 -- 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
name too long problem?
In the latest 3.1 I get this in our backup: filename overflows max-path len by 1: filename overflows max-path len by 1: filename overflows max-path len by 9: filename overflows max-path len by 7: filename overflows max-path len by 4: filename overflows max-path len by 5: filename overflows max-path len by 6: 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? -- 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
