This problem has persisted for as long as I've used rsync. When the --delete option is used, not all files are deleted from the target, even though said files are not present in the source. The particular cases that cause this are when the target has a directory with files, and the source is something else, at least a symlink (this is the case I have seen). I'm taking a guess to say that when the checks for deletion is done, it fails to do a recursion into the target directory to delete the files therein because the source didn't have a directory there. -- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ | -----------------------------------------------------------------
>>>>> "PH" == Phil Howard <phil-rsync@ipal.net> writes:PH> This problem has persisted for as long as I've used rsync. When PH> the --delete option is used, not all files are deleted from the PH> target, even though said files are not present in the source. The PH> particular cases that cause this are when the target has a PH> directory with files, and the source is something else, at least a PH> symlink (this is the case I have seen). [...] Even when using --force --delete?
tim.conway@philips.com
2002-Jan-29 01:47 UTC
option --delete still not completely working (2.5.2)
There you go - the symlink versus the populated directory. It's kind of a
safety. To bypass it, add "--force".
--force
This options tells rsync to delete directories even if
they are not empty. This applies to both the --delete
option and to cases where rsync tries to copy a normal
file but the destination contains a directory of the
same name.
Since this option was added, deletions were reordered
to be done depth-first so it is hardly ever needed
anymore except in very obscure cases.
We have cases like this, and --force was the solution.
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
Phil Howard <phil-rsync@ipal.net>
Sent by: rsync-admin@lists.samba.org
01/26/2002 07:15 PM
To: rsync@samba.org
cc: (bcc: Tim Conway/LMT/SC/PHILIPS)
Subject: option --delete still not completely working (2.5.2)
Classification:
This problem has persisted for as long as I've used rsync. When
the --delete option is used, not all files are deleted from the
target, even though said files are not present in the source.
The particular cases that cause this are when the target has a
directory with files, and the source is something else, at least
a symlink (this is the case I have seen). I'm taking a guess to
say that when the checks for deletion is done, it fails to do a
recursion into the target directory to delete the files therein
because the source didn't have a directory there.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------
tim.conway@philips.com
2002-Jan-29 05:17 UTC
option --delete still not completely working (2.5.2)
Like i said, I think it's a kind of a safety. Going down entire directory
trees that don't exist on the master can wipe out a whole lot of data,
perhaps unintentionally. I suspect that close to 100% of people using
--delete pair it with --force. Without -force, it will not replace a
directory with something else. It's kind of a case of "we don't
want to
by default destroy things in places that don't even exist on the source.
It's a lot like the -f option to rm. you do a rm -r, even as root, and it
doesn't go where it's not explicitly permitted, but add -f (meaning I
REALLY MEAN IT), it'll do it. (Has this changed since i last tested it?).
Tim Conway
tim.conway@philips.com
303.682.4917
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn,
19061,29556,8289,28271,29800,25970,8304,25970,27680,26721,25451,25970),
".\n" '
"There are some who call me.... Tim?"
Phil Howard <phil-rsync@ipal.net>
01/28/2002 09:02 AM
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: rsync@samba.org
Subject: Re: option --delete still not completely working (2.5.2)
Classification:
On Mon, Jan 28, 2002 at 06:47:31AM -0800, tim.conway@philips.com wrote:
| There you go - the symlink versus the populated directory. It's kind of
a
| safety. To bypass it, add "--force".
| --force
| This options tells rsync to delete directories even if
| they are not empty. This applies to both the --delete
| option and to cases where rsync tries to copy a normal
| file but the destination contains a directory of the
| same name.
|
| Since this option was added, deletions were reordered
| to be done depth-first so it is hardly ever needed
| anymore except in very obscure cases.
|
| We have cases like this, and --force was the solution.
I'm still curious why --delete by itself didn't remove the members of
the directory at the target, since those didn't exist at the source.
It would have been helpful if the --delete documentation made a
reference to --force.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ |
-----------------------------------------------------------------