error in logging (version 3.1.0)

[Matt McCutchen]

On Sat, 2009-11-07 at 00:36 -0200, Carlos Carvalho wrote:
> I use rsync -ii so that it logs *all* actions. Further, I don't use
> any delete option but use --force. This means that if there's a name
> collision rsync deletes files or directories. Here's an example:
> 
> 0 0        *deleting   rwxrwsr-x 1969/12/31-21:00:00 scm/linux/kernel/git/amit/vs-kernel.git/objects/38
> 0 0        *deleting   rwxrwsr-x 1969/12/31-21:00:00 scm/linux/kernel/git/amit/vs-kernel.git/objects

I guess some ancestor of
"scm/linux/kernel/git/amit/vs-kernel.git/objects" became a
non-directory?  That seems unlikely to me.

> Therefore I didn't expect to find any of these directories after the
> sync is finished. However I get:
> 
> % ls scm/linux/kernel/git/amit/vs-kernel.git/objects
> 09  15  2d  82  a8  bc  cf  e0  ff
> 
> It might be that for some reason rsync created the directory again.

I don't think so.  I only know of one rare case in which rsync would
delete and recreate a directory, and I don't think it applies here: when
the file list contains an ancestor and a descendant but not the
directory itself, which can only happen with --relative
--no-implied-dirs and protocol <= 29.

> BUT *no other lines* with
> scm/linux/kernel/git/amit/vs-kernel.git/objects appear in the log. So
> we have two possibilities: either rsync lied and didn't delete the
> directory, or it created it again and didn't tell it in the log.

Do you have a reproducible test case?

-- 
Matt