Robustness: sometimes write times after having renamed the temp file

Guillaume Outters guillaume-rsync at
Tue Nov 29 06:51:59 UTC 2016


Mac OS X 10.9 has the bad habit of considering a rename on an UDF FS as 
a file change; that is:

> touch -t 201010101010 test
> ls -l test
-rw-r--r--  1 gui  staff  0 10 oct  2010 test
> mv test fail
> ls -l fail
-rw-r--r--  1 gui  staff  0 29 nov 00:19 fail

rsync.c (3.1.2), in archive mode, calls set_file_attrs *before* 
renaming .file.XXXXXX to file. So, in the aforementioned case, all times 
beautifully crafted on the file get lost.

I would be glad to know if other OSes / FS combinations get such a 
disturbing implementation.

Could this behavior be ground to an rsync enhancement request?

In this case, the attached POC code (well, a bit more than a POC, 
because it is currently handling a 600 GB "rsync -a" to an UDF disk) 
could serve as a base for an implementation.
It relies on the first temp file rename to detect bad behavior from the 
FS, and if so, all subsequent set_file_attrs get delayed to after the 

Everyone have a nice day!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rsync.modtime_after_rename.patch
Type: text/x-diff
Size: 2682 bytes
Desc: not available
URL: <>

More information about the rsync mailing list