[Bug 13445] New: Fuzzy searching in link-dest tries to open regular file as directory

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=13445

            Bug ID: 13445
           Summary: Fuzzy searching in link-dest tries to open regular
                    file as directory
           Product: rsync
           Version: 3.1.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
          Assignee: wayned at samba.org
          Reporter: alguien at respiranto.de
        QA Contact: rsync-qa at samba.org

Created attachment 14205
  --> https://bugzilla.samba.org/attachment.cgi?id=14205&action=edit
Patch to handle ENOTDIR in flist.c:send_directory()

If rsync is called with doubled --fuzzy flag and --link-dest
(or --compare-dest, --copy-dest), it fails in a situation as described below.
The problem appears in both version 3.1.3 and the current development version
3.1.4dev.


Let there be the following directory structure

$PWD/
`- src/
   `- a/
      `- f
`- ref/
   `- a

where src/a/f and ref/a are regular files and the files src/a and ref/a
actually have the same name.

To create it:

$ mkdir -p src/a ref; touch src/a/f ref/a


Now let rsync copy files from src/ to tgt/ linking to (fuzzy matched) files
in ref/, as follows:

$ rsync --recursive --fuzzy --fuzzy --link-dest=../ref src/ tgt

Rsync fails with:

rsync: opendir "/tmp/rsync-test/tgt/../ref/a" failed: Not a directory (20)
rsync error: some files/attrs were not transferred (see previous errors) (code
23) at main.c(1189) [sender=3.1.3]


This is due to rsync trying to find a fuzzy match for src/a/f in ref/a, which
obviously fails, as ref/a is not a directory.

The problem arises in flist.c:send_directory() when called by
flist.c:get_dirlist() which in turn is called by
generator.c:recv_generator(), where the former two are called with ../ref/a .

Since the case of an inexistant directory is already handled in 
flist.c:send_directory(), that is probably also where to handle the case of
the filename referring to a file not being a directory.  See the attached
patch.

In fact, I am not sure that it is a good idea to just ignore ENOENT and
ENOTDIR if !am_sender, since those should also possibly mean a real error.
Or am I mistaken here?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.