Using mkstemp adds on 7 characters to the filename, which creates a problem when the filename is below, but close to, the limit of the filesystem. You can see this when rsync'ing from one ecryptfs filesystem to another, which will fail even though both have the exact same 143-byte filename limit, if a filename consists of more than 136 bytes. Is there any reason the .XXXXXX in the argument to mkstemp can't *replace* the last 7 characters in the filename, instead of being appended to it?
https://git.samba.org/rsync.git/?p=rsync.git;a=blob;f=receiver.c;hb=3267d6a9ceeefad438080b17c02daa7775820803#l143 Wait, it actually adds 8 characters to it in total, there's a dot prepended at the beginning to.
Triple post. Shouldn't it also use e.g. f_namelen from statfs() at runtime instead of a compile-time constant? And MAXPATHLEN doesn't even seem to reflect reality, since it's not actually limited to that on Linux. https://lists.debian.org/debian-hurd/2012/01/msg00166.html
I'm also encountering problems regarding mkstemp "file name too long error" when rsyncing to an ecryptfs filesystem. Probably, rsync should try to handle this in a smarter way. A secondary problem I see is that, even if this error is given, the whole file is transferred from source to target anyway, although not actually saved on the target. So, if the file is huge and the bandwidth is low, this is a serious waste. Using rsync 3.0.9 on local side (target) and rsync 3.1.1 on remote side (source).