Bug 21395 - Rsync fails on non existent directories
Summary: Rsync fails on non existent directories
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High critical
Target Milestone: ---
Assignee: Marc Krämer
QA Contact:
URL: https://bugzilla.samba.org/show_bug.c...
Keywords: UPSTREAM
Depends on:
Reported: 2017-07-29 11:46 CEST by Marc Krämer
Modified: 2019-03-04 16:51 CET (History)
1 user (show)

See Also:
Source RPM: rsync-3.1.2-1.mga6.src.rpm
Status comment:


Description Marc Krämer 2017-07-29 11:46:06 CEST
If rsync tries to sync a non existen directory it fails instead of ignoring it and continue. This breaks some scripts.

For details see upstream upstream bugreport.

Can you apply the suggested patch?
Comment 1 Marja Van Waes 2017-07-29 22:28:32 CEST

(In reply to M K from comment #0)
> If rsync tries to sync a non existen directory it fails instead of ignoring
> it and continue. This breaks some scripts.
> For details see upstream upstream bugreport.
> Can you apply the suggested patch?

The author of that patch says:
> Following patch fixes it for me, albeit it ignores this kind of error now
> always:
(See https://bugzilla.samba.org/show_bug.cgi?id=12569#c0 )

That sounds as if it also ignores such errors when --delete-missing-args and --ignore-errors are _not_ used.

Assigning to all packagers collectively, since there is no registered maintainer for this package.

Keywords: (none) => UPSTREAM
Assignee: bugsquad => pkg-bugs
CC: (none) => marja11

Comment 2 David Walser 2017-07-31 02:20:40 CEST
We certainly shouldn't take such a patch if upstream hasn't either.  Also, failing on missing directories is generally a good thing with rsync, as it helps prevent mistakes (such as doing an rsync involving a mounted filesystem that happens to not be currently mounted).
Comment 3 Marc Krämer 2017-07-31 11:23:45 CEST
maybe you are right, but this is a changed behaviour which worked in mga5 and makes scripts fail, since there is no "force" available which lets you ignore it. For me a server creates files, they are periodically synced, but it can happen the file (dir) specified disappears before rsync can copy it. So the script fails.

At least there should be any option to disable the new behaviour. Upstream even has not commented this bug in months. As you can see the latest release was just planned as a security release after 2 years there is not much development in rsync anymore.
Comment 4 Marc Krämer 2017-09-22 12:10:18 CEST
Is there any decission on this subject. I've reinstalled the mga5 package which fxied the issue for me. But this has to be fixed for future versions.
Should I post this to upstream? This bug breaks numerous scripts.
Comment 5 Marc Krämer 2018-05-09 12:00:05 CEST
@David: I'm not sure if there is much development/maintenance going on upstream. I've posted upstream, but there is no reaction. Even it looks like there is only one man maintaining this package.

One thing is sure, the updated package has changed its behavior and there are good reasons to keep the old behavior: 
file-lists of changed files/directories are generated by scripts and should process after some time (e.g. 30s). If the user has deleted the local directory in between, the old rsync continues while the new one just fails). Since there is always time between passing the file list and the execution of rsync there is always a chance for the new rsync to fail. As the man page states this is the idea of --ignore-missing-args and --ignore-errors. It should continue, not fail in case of errors.
Comment 6 Marc Krämer 2018-05-09 12:02:27 CEST
I can do the patching, and it would not have effect on others (as you stated missing dirs), since you have to specify the given options to do so.
Comment 7 Marc Krämer 2018-10-07 13:17:35 CEST
The problem is "solved" upstream. There is an option "--no-implied-dirs" which solves this problem. I'm not sure, if really everyone is aware of this option.

Resolution: (none) => WONTFIX

Comment 8 Marc Krämer 2018-10-09 18:34:29 CEST
I have to reopen this issue. By test it looks like the behaviour still is changed!

Resolution: WONTFIX => (none)

Comment 9 Marc Krämer 2019-02-27 14:18:35 CET
this is still a big issue for me, can we please change back to the old behaviour? There is NO workaround!

Priority: Normal => High

Marc Krämer 2019-03-04 15:11:52 CET

Assignee: pkg-bugs => mageia

Comment 10 Marc Krämer 2019-03-04 16:51:08 CET
Fixed in cauldron.

Version: 6 => Cauldron

Comment 11 Marc Krämer 2019-03-04 16:51:19 CET
fxied in cauldron

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.