Matt McCutchen
2008-Mar-10 04:23 UTC
Rsync itemizing "t" (should be "T") when lutimes fails on recreated symlink
IIUC, the new philosophy of symlink times is that -t preserves them to the extent that they are settable; when they aren't, it's just as if -t wasn't given. But rsync breaks this principle in the following case. Suppose rsync is configured with HAVE_LUTIMES enabled but the lutimes call doesn't actually work (I simulated this via the attached patch). When rsync recreates a destination symlink to update its target path, rsync will fail to preserve the time, but it nevertheless itemizes "t". It should itemize "T" because the time is being incidentally changed, not preserved. To reproduce: ln -s ta a sleep 1 ln -s tb b rsync-dev -i -lt a b stat --format='%Y %n' a b Output: # Rsync claims to have preserved the time... cL..t...... a -> ta # ... but it differs 1205122328 a 1205122329 b The problem is that, for a recreated symlink (as opposed to a tweaked one), the generator itemizes ITEM_REPORT_TIME whether it succeeded or failed in setting the time. On a push, the sender is doing the logging and can't check the generator's FLAG_TIME_FAILED, so there is no way for it to tell these two cases apart; they have to look different in the itemize flags. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: fake-lutimes.diff Type: text/x-patch Size: 706 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20080310/c9373066/fake-lutimes.bin
Wayne Davison
2008-Mar-11 04:45 UTC
Rsync itemizing "t" (should be "T") when lutimes fails on recreated symlink
On Mon, Mar 10, 2008 at 12:23:15AM -0400, Matt McCutchen wrote:> When rsync recreates a destination symlink to update its target path, > rsync will fail to preserve the time, but it nevertheless itemizes "t".This is now fixed in the git repository along with a couple other glitches that I turned up in the itemized output. As a part of all the fixing, I changed the itemized output of symlinks, devices, and special files to put a 'c' into the checksum/change field. This ensures that changes that are happening show up in the itemized output and are able to be differentiated from the copying of unchanged items when using the --copy-dest option. ..wayne..
Matt McCutchen
2008-Mar-11 05:04 UTC
Rsync itemizing "t" (should be "T") when lutimes fails on recreated symlink
On Mon, 2008-03-10 at 21:44 -0700, Wayne Davison wrote:> On Mon, Mar 10, 2008 at 12:23:15AM -0400, Matt McCutchen wrote: > > When rsync recreates a destination symlink to update its target path, > > rsync will fail to preserve the time, but it nevertheless itemizes "t". > > This is now fixed in the git repository along with a couple other > glitches that I turned up in the itemized output.Nice! It works! I see you also converted the non-symlink itemize condition to a ?:, which I had been thinking of proposing. Matt
Possibly Parallel Threads
- DO NOT REPLY [Bug 7621] New: Special handling of lutimes ENOSYS failures does not work as intended
- DO NOT REPLY [Bug 4745] New: Use lchmod and lutimes whenever possible
- [Bug 2913] New: rsync of symlinks on >=bsd needs lutimes(2) and lchmod(2)
- [Bug 2913] rsync of symlinks on >=bsd needs lutimes(2) and lchmod(2)
- Rsync itemizing "p" even when -p, -E are off