rsync - Nov 2016 - Robustness: sometimes write times after having renamed the temp file

Hello,

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 
rename.

Everyone have a nice day!

-- 
Guillaume
-------------- 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:
<http://lists.samba.org/pipermail/rsync/attachments/20161129/f02f61c5/rsync.modtime_after_rename.diff>

I believe some work on this was happening at one point in rsync (not specific to
OS X).

In terms of your issues specifically, would the fuzzy option possibly help you?
> --fuzzy     find similar file for basis if no dest file

Could you report if it makes a difference for your use case?

---------------------------------------------------------------------
This email is protected by LBackup, an open source backup solution.
http://www.lbackup.org

Le 2016-11-30 11:19, Henri Shustak a écrit :
> I believe some work on this was happening at one point in rsync (not
> specific to OS X).
I would be interested to know which problematic cases motivated this 
work; I did not find trace of it in the source.
> In terms of your issues specifically, would the fuzzy option possibly 
> help you?
Hmm, no, it doesn't do anything.
fuzzy would help on naming problems; in the "dest is UDF" case (with 
the default, --no-inplace, mode: 'file' gets tranfered as 
'.file.XXXXXX', then renamed to 'file'):
- the name is correctly renderered
- but the timestamps are not (well, they are transfered, but then reset 
to 'now' by the FS during the final renaming)

Thus my patch to swap the timestamping with the renaming when it is 
detected that the FS has this flaw.

-- 
Guillaume