Bug 10989 - "copying unsafe symlink" warnings occur if nothing changed
Summary: "copying unsafe symlink" warnings occur if nothing changed
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.1
Hardware: All Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-06 02:40 UTC by Jim Avera
Modified: 2015-01-11 04:36 UTC (History)
0 users

See Also:


Attachments
Demo script (563 bytes, application/x-sh)
2014-12-06 02:40 UTC, Jim Avera
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2014-12-06 02:40:08 UTC
rsync recently began issuing "copying unsafe symlink" warnings with --verbose even if the file in question has not changed in any way.   This pollutes the output so you can't easily see what *has* changed.   for example, I update a web server tree which contains many symlinks to files outside the source tree on the source machine (and which are copied as plain files to the destination, as expected).   Now every time I run rsync to do an update, I see a warning for every one of those files, even though nothing has changed in any way.

So I'm requesting that rsync NOT issue that warning except when the destination file does not exist or is changing (i.e. content, permissions, or something)  But NOT if nothing has changed at all.

I'll attach a demo script which shows the problem (with rsync 3.1.1 on Ubuntu 14.10 64bit).
Comment 1 Jim Avera 2014-12-06 02:40:30 UTC
Created attachment 10497 [details]
Demo script
Comment 2 Jim Avera 2015-01-11 01:57:19 UTC
A much more serious problem is that when "unsafe" symlinks are copied pursuant to the --copy-unsafe-links option, they are all treated as I/O ERRORS.

This prevents --delete from ever working.
Comment 3 Jim Avera 2015-01-11 04:36:31 UTC
Sorry, please ignore comment#3 (there was so much noise from the warnings that I didn't see that one of the 100s of links was in fact broken, and thus the IO Error was legitimate).