name too long problem?

Carlos Carvalho carlos at fisica.ufpr.br
Wed Feb 15 14:40:16 MST 2012


Kevin Korb (kmk at 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 (carlos at fisica.ufpr.br) wrote on 15 February 2012 18:09:
 >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>

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.


More information about the rsync mailing list