Bug 3935 - replacing a full directory with symlink with --delete-after produces cryptic message
replacing a full directory with symlink with --delete-after produces cryptic ...
Status: CLOSED FIXED
Product: rsync
Classification: Unclassified
Component: core
2.6.7
x86 Linux
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-14 10:24 UTC by Christian Holtje
Modified: 2006-10-15 13:26 UTC (History)
0 users

See Also:


Attachments
A test case (467 bytes, application/x-shellscript)
2006-07-14 10:25 UTC, Christian Holtje
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Holtje 2006-07-14 10:24:04 UTC
What Happned:
   On the source, a directory with files is changed to a symlink.
   rysnc -ra --delete-after will then generate the following message:
   rsync: delete_file: rmdir "/tmp/rsync.bug.11080/dest/somedir" failed: Directory not empty (39)
   rsync error: some files could not be transferred (code 23) at
   main.c(791)

What I Expected:
   I expected the directory to be replaced with a symlink (like
   --delete would have done)
   OR
   I expected the directory to be deleted at the end (because of
   --delete-after) but the symlink not to be sync'ed.  I would expect
   it to still raise an error, but the next run would fix it (since
   the directory is done).
   OR
   I expected the error message to explain how I could fix this
   problem.

I can see why it would fail during the sync phase, but the delete
phase should have deleted it after the syncing part, since no IO
errors were detected on the sending side.

I have attached a simple script to generate this error on command.

Ciao!
Comment 1 Christian Holtje 2006-07-14 10:25:21 UTC
Created attachment 2034 [details]
A test case

This script will leave a /tmp/rsync.bug.NNNN directory around if it fails (which it does in the current version of rsync).
You may want to clean up after the script before running it so that only one directory hangs around.

Ciao!
Comment 2 Wayne Davison 2006-07-14 20:39:18 UTC
Firstly, thanks for the detailed bug-report.  This bug was fixed in 2.6.7:

  - Got rid of the need for --force to be used in some circumstances with
    --delete-after (making it consistent with --delete-before/-during).

So, you can either upgrade to 2.6.8, or use the --force option when using --delete-after.