Bug 5867 - rsync with ACLs resets mtime on targets
rsync with ACLs resets mtime on targets
Product: rsync
Classification: Unclassified
Component: core
x86 FreeBSD
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
Depends on:
  Show dependency treegraph
Reported: 2008-11-02 07:48 UTC by samba
Modified: 2009-01-27 09:46 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description samba 2008-11-02 07:48:19 UTC
On FreeBSD (v6 and v7), rsync (v3.0.4) with the extented ACLs patch has a problem.

The ACLs flag works, but when it is used, the mtime of the files on on the receiving system are set to the current time.  This is a bit annoying in itself, but creates a larger problem because any later rsync actions on the same files see the files as _different_, meaning that _all_ the files are recopied -- which more or less defeats the purpose of using rsync.

Yes, I understand that setting ACLs on a file changes the mtime of the file.  But, as rsync is able to (re)set mtimes I would think that this shouldn't should be an issue when using rsync.

After some searching around, I found some discussion (relating to Macs, actually) that suggests that the problem is that with the ACLs patch enabled, rsync modifies the ACLs on the target files _after_ setting the mtime, which seems to me (at least) to be a bug.
Comment 1 Wayne Davison 2008-12-27 13:13:28 UTC
Do you mean the fileflags.diff patch? ACLs are supported by default these days, though there is also an acls.diff patch that adds a backward-compatible mode for interfacing with rsync versions prior to 3.0.0.
Comment 2 samba 2008-12-28 05:03:18 UTC
It doesn't seem to matter whether it is default or backward-compatible.

The problem is not with the setting of ACLs itself, but that setting ACLs changes the new file's mtime.

If I rsync (-avxHA) the dir 'gbyshenk' to the new dir 'gbyshenk_acl', it works, and the ACLs are copied.  But it seems that the mtime has been changed to now ('now' being the time the rsync was run).

This is a problem in and of itself, but also creates a new problem, in that, if I then re-run rsync, it sees the new files as different than the old files, and proceeds to copy _everything_ again, rather than only the new/changed files. If I run rsync (-avxH -- _without_ the -A flag), then rsync behaves as it should.
Comment 3 Timur Bakeyev 2009-01-25 14:24:44 UTC
This is a bug/misfeature in the FreeBSD ACLs->UFS2 code.
Here is a bit of more discussion about it:
In general, it should be fixed on a FreeBSD side, but, possibly, rsync
can work around it too.
Comment 4 samba 2009-01-27 09:46:22 UTC
Timur is correct, of course.

My apologies; when I raised this earlier I was advised that it looked to be an 'rsync' problem and I should file the bug here.

Robert Watson has provided some patches to the FreeBSD ffs code that appear to solve the more general problem, as well as the reported rsync problem.

(I am guessing that 'invalid' is the proper resolution code for this 'bug'.)