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