info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Bug 11481] --ignore-errors must be a separate option
2 views
Skip to first unread message
samba...@samba.org
Sep 1, 2015, 12:27:56 PM9/1/15
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #1 from Kevin Korb <rs...@sanitarium.net> ---
--force exists to force --delete to work even when there are errors. That is
the only behaviour that rsync changes based on errors. So what would you
expect --ignore-errors to change when there is no --delete?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--- Comment #1 from Kevin Korb <rs...@sanitarium.net> ---
--force exists to force --delete to work even when there are errors. That is
the only behaviour that rsync changes based on errors. So what would you
expect --ignore-errors to change when there is no --delete?
--
You are receiving this mail because:
You are the QA Contact for the bug.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
samba...@samba.org
Sep 1, 2015, 1:06:25 PM9/1/15
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #2 from Muralidhar N <muralid...@yahoo.co.in> ---
Yes. we must have --ignore-errors independent of --delete and also --force
independent of --delete. sometimes we may not use --delete at all and want to
continue with rsync even when errors are there and also sometimes rsync may
refuse to run, so --force.
--- Comment #2 from Muralidhar N <muralid...@yahoo.co.in> ---
Yes. we must have --ignore-errors independent of --delete and also --force
independent of --delete. sometimes we may not use --delete at all and want to
continue with rsync even when errors are there and also sometimes rsync may
refuse to run, so --force.
samba...@samba.org
Sep 1, 2015, 1:53:55 PM9/1/15
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #3 from Kevin Korb <rs...@sanitarium.net> ---
Rsync does continue on errors unless those errors are fatal (like a failure to
connect). Sounds more like what you want is a retry option which is easy
enough to script.
--- Comment #3 from Kevin Korb <rs...@sanitarium.net> ---
Rsync does continue on errors unless those errors are fatal (like a failure to
connect). Sounds more like what you want is a retry option which is easy
enough to script.
samba...@samba.org
Sep 13, 2015, 7:53:56 PM9/13/15
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
Wayne Davison <way...@samba.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #4 from Wayne Davison <way...@samba.org> ---
I believe you're trying to make an enhancement suggestion to extend what
--ignore-errors does. If so, what more are you wanting it to do?
Wayne Davison <way...@samba.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #4 from Wayne Davison <way...@samba.org> ---
I believe you're trying to make an enhancement suggestion to extend what
--ignore-errors does. If so, what more are you wanting it to do?
samba...@samba.org
Jul 31, 2016, 10:11:53 AM7/31/16
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #5 from samb...@phox.ca ---
@Kevin, your understanding here is incorrect: rsync bails entire transfers on
things that are NOT fatal to the entire transfer, and --ignore-errors overrides
this. I ended up stumbling upon this bug as a result of trying to remediate
the behaviour in the case of the following error:
rsync: write failed on "/mnt/PICO3/foo.tbz2": File too large (27)
--ignore-errors does indeed override the fail-through behaviour in this
otherwise non-fatal instance.
(Hint: I'm rsyncing to a vfat filesystem ;), and this file is about 4.5G. In
addition to the fact that the --ignore-errors documentation clearly needs
revising, this raises two additional, separate bugs pertaining to a) not caring
what errno is, and b) the fact that in the spirit of saving bandwidth we should
use fallocate(2) unless a --skip-[f]allocate switch (e.g. for compressed
destination filesystems) is presented, so we're not transferring data that we
could have predicted would get thrown out... and a third for c) --progress
tells us the wrong thing when the file can no longer be grown, indicating that
the transfer is actually at 100%!)
--- Comment #5 from samb...@phox.ca ---
@Kevin, your understanding here is incorrect: rsync bails entire transfers on
things that are NOT fatal to the entire transfer, and --ignore-errors overrides
this. I ended up stumbling upon this bug as a result of trying to remediate
the behaviour in the case of the following error:
rsync: write failed on "/mnt/PICO3/foo.tbz2": File too large (27)
--ignore-errors does indeed override the fail-through behaviour in this
otherwise non-fatal instance.
(Hint: I'm rsyncing to a vfat filesystem ;), and this file is about 4.5G. In
addition to the fact that the --ignore-errors documentation clearly needs
revising, this raises two additional, separate bugs pertaining to a) not caring
what errno is, and b) the fact that in the spirit of saving bandwidth we should
use fallocate(2) unless a --skip-[f]allocate switch (e.g. for compressed
destination filesystems) is presented, so we're not transferring data that we
could have predicted would get thrown out... and a third for c) --progress
tells us the wrong thing when the file can no longer be grown, indicating that
the transfer is actually at 100%!)
samba...@samba.org
Jul 31, 2016, 10:23:20 AM7/31/16
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #6 from Paul N <samb...@phox.ca> ---
Slightly correction to my above comment, implying 1-2 more bugs:
- When --ignore-errors is not specified, all subsequent files fail with
'Operation not permitted (1)', which is incorrect, at least at the environment
level (the receiver might be emitting this, but not for any earthly reason as
it were).
- Using --ignore-errors also does The Wrong Thing: Files after the problematic
file (foo.tbz2 in my above example) are shown by --progress as transferred at
increasingly fast speeds, in this case 150-200MB/sec, and the last couple
approaching twice that... without stracing this these appear to be roughly the
source filesystem read speeds?!
So, --ignore-errors being misdocumented and misimplemented appear to have come
as a pair.
--- Comment #6 from Paul N <samb...@phox.ca> ---
Slightly correction to my above comment, implying 1-2 more bugs:
- When --ignore-errors is not specified, all subsequent files fail with
'Operation not permitted (1)', which is incorrect, at least at the environment
level (the receiver might be emitting this, but not for any earthly reason as
it were).
- Using --ignore-errors also does The Wrong Thing: Files after the problematic
file (foo.tbz2 in my above example) are shown by --progress as transferred at
increasingly fast speeds, in this case 150-200MB/sec, and the last couple
approaching twice that... without stracing this these appear to be roughly the
source filesystem read speeds?!
So, --ignore-errors being misdocumented and misimplemented appear to have come
as a pair.
samba...@samba.org
Jul 31, 2016, 10:24:43 AM7/31/16
to
https://bugzilla.samba.org/show_bug.cgi?id=11481
--- Comment #7 from Paul N <samb...@phox.ca> ---
(Sorry, more...)
The greatest sin of how --ignore-errors misbehaves in the above case is that
the only error REPORTED at the end of the transfer is the one for the oversized
file that caused the problem... so a bunch of files are shown as transferred by
--progress and yet never were, so perhaps this is --lie-about-errors :)
--- Comment #7 from Paul N <samb...@phox.ca> ---
(Sorry, more...)
The greatest sin of how --ignore-errors misbehaves in the above case is that
the only error REPORTED at the end of the transfer is the one for the oversized
file that caused the problem... so a bunch of files are shown as transferred by
--progress and yet never were, so perhaps this is --lie-about-errors :)
0 new messages