Possible bug - delete complains about parent directory in new
version
Lloyd J. McDonald
ljmx at comcast.net
Wed May 18 20:30:58 GMT 2005
I have what I believe to be a bug in the behavior of the current (2.6.4)
version of rsync. While trying to upgrade from version 2.5.2 to the
current version (for security concerns), I noticed the following
difference in behavior between the two versions which is preventing the
upgrade:
If you have a directory tree on the target such as the following:
dir/pdf/file1.pdf
dir/pdf/file2.pdf
...
dir/pdf/fileN.pdf
If the "dir/pdf" directory does not exist on the source, and you have an
exclude list which excludes "*.pdf", rsync 2.6.4 fails to synchronize
the two directories - it fails with:
rsync: delete_file: rmdir "dir/pdf" failed: File exists (17)
...
rsync error: some files could not be transferred (code 23) at
main.c(789)
However version 2.5.2 quietly synchronizes the two directory trees
without error.
The error (17) above is due to the fact that "dir/pdf" still contains
file*.pdf. However, since "dir/pdf" does not exist on the source, it
tries to remove the directory, even though the directory is not empty.
Version 2.5.2 seems "smart" enought to realize that it should not
attempt to delete a directory containing an excluded file, but 2.6.4
blindly tries to delete the directory which is why I call this a
"possible bug".
One might be tempted to simply tell me "Why not exclude 'pdf/'?" or
similar. However, in this case you run into exactly the same problem if
the parent of "pdf" does not exist. The problem is not fixed it's moved...
The directory trees hinted at above are actually used for independent
web developer synchronization to a single target web-site tree.
Different folk do the web development, image development, and pdf
creation. Each group has their own rsync scripts which 'layer in' the
content from their respective trees, which explains why the "pdf"
directories do not (always) exist on the source (and are excluded).
Also, the "pdf" (and other similar directories) are not at consistent,
predictable locations in the directory tree, which make detailed exclude
lists unworkable. Again, all works fine with version 2.5.2, but fails
with 2.6.4.
The rsync command used is as follows:
/usr/local/bin/rsync -rl -v -v --delete --exclude-from=exclude-list --rsh="ssh -i $HOME/.ssh/rsync_key" --rsync-path=/usr/local/bin/rsync /source_dir host:/target_dir
The above situation is very reproducible. I have spent a substantial
amount of time looking for this in postings, without success. I've also
done considerable testing with the two versions mentioned and exclude
lists, again without success. Is this new behavior a bug that has crept
in, or was the behavior changed intentionally? If it is a bug, can I
get it added to the list to get fixed for an uncoming version?
Thanks,
LJ McDonald
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the rsync
mailing list