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: <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> 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
