Bug 5079 - rsync: failed to open "/path/to/file", continuing: Permission denied (13)
rsync: failed to open "/path/to/file", continuing: Permission denied (13)
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.0
All All
: P3 minor
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-13 11:23 UTC by Peter Oliver
Modified: 2008-07-26 10:19 UTC (History)
0 users

See Also:


Attachments
s/FERROR/FINFO/ (406 bytes, patch)
2007-11-13 11:27 UTC, Peter Oliver
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Oliver 2007-11-13 11:23:52 UTC
In the event that rsync encounters a file on the receiving end that it cannot read, it will treat the file as if it is empty, try to replace it, and issue the following message:

    rsync: failed to open "/path/to/file", continuing: Permission denied (13)

However, even if it succeeds it will also issue this messages:

    rsync error: some files could not be transferred (code 23) at main.c(789)

This leads the user (and any scripts checking the return code) to believe that the transfer has failed, when in fact it has succeeded.
Comment 1 Peter Oliver 2007-11-13 11:27:45 UTC
Created attachment 2966 [details]
s/FERROR/FINFO/

Turning this error message into a warning that does not set a return code appears to be a simple matter of changing FERROR to FINFO for this message.
Comment 2 Wayne Davison 2007-11-22 12:34:29 UTC
I have expanded the error codes that a protocol-30 rsync can send so that it can indicate that a message is an error (which should go to stderr) without causing the "some files could not be transferred" error at the end.  So, this is now fixed in the git repository.