rsync - Dec 2005 - batch applied: "Directory not empty (66)"

"rsync  version 2.6.6  protocol version 29"

In my source I have a directory that changed to a file.  I know this
requires --force or --delete, but using --only-write-batch I get no
error until I attempt to apply the batch.

This confused me for a bit.  Is this intended behavior?

Also, unrelatedly, when rsync refuses to apply a specific change
from a batch due to the destination not being in the right state, is
there any way to get more detail on what aspect triggered the
refusal?

Thanks,

RSK
-- 
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

On Wed, Dec 07, 2005 at 10:45:35PM -0800, Raymond Keller
wrote:
> In my source I have a directory that changed to a file.  I know this
> requires --force or --delete, but using --only-write-batch I get no
> error until I attempt to apply the batch.
That''s correct -- there''s no problem generating the batch when
the
destination is not being modified (rsync notices that the file changed
into a dir, but doesn''t need to check if it is empty or not since
it''s
not actually being removed).  When the batch is read back, the user has
the option of using the --force option or not, regardless of how the
batch was made (since it doesn''t affect the making of a batch).  In
fact, there is no problem if the user first uses the batch file without
--force, notices that it is needed, and then re-runs the same batch file
with --force since rsync skips all the already-applied changes prior to
the change that caused the halt.
> Also, unrelatedly, when rsync refuses to apply a specific change
> from a batch due to the destination not being in the right state, is
> there any way to get more detail on what aspect triggered the
> refusal?
I assume you mean the "Skipping batched update" message, that only
occurs for one reason:  the file is up-to-date (for whatever definition
of up-to-date was in effect when the batch was created).  The only other
refusal happens when the changes get applied and the file fails the
checksum (causing rsync to discard the bogus file unless --partial was
in effect).

..wayne..

* Wayne Davison (wayned@samba.org) [20051209 12:10]:
> On Wed, Dec 07, 2005 at 10:45:35PM -0800, Raymond Keller wrote:
> > In my source I have a directory that changed to a file.  I know this
> > requires --force or --delete, but using --only-write-batch I get no
> > error until I attempt to apply the batch.
> 
> That''s correct -- there''s no problem generating the batch
when the
> destination is not being modified (rsync notices that the file changed
> into a dir, but doesn''t need to check if it is empty or not since
it''s
> not actually being removed).  When the batch is read back, the user has
> the option of using the --force option or not, regardless of how the
> batch was made (since it doesn''t affect the making of a batch). 
In
> fact, there is no problem if the user first uses the batch file without
> --force, notices that it is needed, and then re-runs the same batch file
> with --force since rsync skips all the already-applied changes prior to
> the change that caused the halt.
I get it; distinct create and apply phases, with their particular
behaviors/needs.

> > Also, unrelatedly, when rsync refuses to apply a specific change
> > from a batch due to the destination not being in the right state, is
> > there any way to get more detail on what aspect triggered the
> > refusal?
> 
> I assume you mean the "Skipping batched update" message, that
only
> occurs for one reason:  the file is up-to-date (for whatever definition
> of up-to-date was in effect when the batch was created).  The only other
> refusal happens when the changes get applied and the file fails the
> checksum (causing rsync to discard the bogus file unless --partial was
> in effect).
I do mean that, yes.  I had the misunderstanding that the
destination file had to be in a state identical to the corresponding
destination file against which the batch was originally created, or
an update would not be applied.  Thanks for clarifying.


I see now how I came into this erroneous idea.  The man page says:

  ``The read-batch option expects the destination tree that it is
  updating to be identical to the destination tree that was used
  to create the batch update fileset.''''

I failed to closely read the following sentences which explain
exactly what you''ve told me here.  Thanks for tolerating (and
graciously answering) a man page question.


And thanks for (maintaining) the software!  Like gajillions of
others these days, I have my backups based on rsync.  52 "snapshots"
of three different systems, spanning two years, taking 31 gigs, with
new snapshots added six times daily.  I couldn''t feel any more
secure if I wore pants with both suspenders _and_ a belt.


RSK