Bug 3198 - rsyncing a file to a dest path where dirname(path) is a file quietly fails
rsyncing a file to a dest path where dirname(path) is a file quietly fails
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.1
All Solaris
: P3 major
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-20 00:14 UTC by Manish Dubey
Modified: 2006-03-12 02:56 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manish Dubey 2005-10-20 00:14:14 UTC
home:~> ls -l foo bar
-rw-r--r--  1 mdubey  users     0 Oct 20 00:03 bar
-rw-r--r--  1 mdubey  users  4105 Oct 20 00:03 foo

home:~> rsync -v foo bar/cuz
wrote 34 bytes  read 20 bytes  108.00 bytes/sec
total size is 4105  speedup is 76.02
home:~> echo $status
0

home:~> ls -l bar 
-rw-r--r--  1 mdubey  users  0 Oct 20 00:03 bar

I have seen this on Solaris (rsync 2.6.1), Redhat (2.6.1) and FreeBSD (2.5.6)
Comment 1 Wayne Davison 2005-10-20 09:45:35 UTC
This has already been fixed in the CVS version, so it will appear in the next
release.

In currently released versions of rsync, the error is hidden unless -vv is
specified, which is clearly wrong (as you discovered).  It is easy to patch this
fix into any version of rsync by looking for the stat() error in generator.c and
removing the "if (verbose > 1)" check.  The code will then look like this:

        rsyserr(FERROR, stat_errno, "recv_generator: failed to stat %s",
                full_fname(fname));
Comment 2 Matt McCutchen 2005-10-20 13:37:00 UTC
A side note in case anyone is interested:

My custom rsync, in order to observe default ACLs correctly, needed a change to
the behavior of "get_local_name".  Even if only a single source file is being
transferred to a single destination file, the receiving rsync changes into the
directory of the destination file.  (In fact, I found the idea of "local names"
so confusing that I rewrote "get_local_name", adding additional comments and
verbose output.)

A side effect of the change is that, on my rsync, "rsync -v foo bar/cuz" will
fail during file selection as it should.  It says:
    rsync: push_dir#2.5 "/path/to/bar/cuz" failed: No such file or directory (2)
    rsync error: errors selecting input/output files, dirs (code 3) at main.c(498)
    rsync: connection unexpectedly closed (8 bytes received so far) [sender]
    rsync error: error in rsync protocol data stream (code 12) at io.c(434)
(I just realized that while the attempted push_dir is correct, the path in the
error message is wrong: it should be "/path/to/bar".  I'll fix this.)

My rsync is available here:
    http://mysite.verizon.net/hashproduct/myrsync/