Either way - as a workaround, you could drop delete-excluded, and
then just finalize the thing with something like: find /bar/ -depth
-name .rsync-partial -exec rm -rf {} \;
I meant more like: -name .rsync-partial -prune -exec .
Shivkumar Venkatasubrahmanyam wrote:
Makes sense. And
Michal Soltys wrote:
Either way - as a workaround, you could drop delete-excluded, and
then just finalize the thing with something like: find /bar/ -depth
-name .rsync-partial -exec rm -rf {} \;
I meant more like: -name .rsync-partial -prune -exec .
Shivkumar Venkatasubrahmanyam
Shivkumar Venkatasubrahmanyam wrote:
... then without -f 'R .rp/', dst/.rp is not removed. With -f 'R .rp/',
it is removed but if dst/a is updated then we have the same issue (exit
with code 23). This is entirely consistent with your strace i.e. code
23 whenever there are two separate
On Mon, Dec 22, 2008 at 09:46:40AM +0100, Michal Soltys wrote:
but ... the dir is not there anymore, thus ENOENT
(due to opendir failing) and rsync's exit code 23.
Yeah, rsync always generates an error if the opendir() call fails in
send_directory(). The attached patch makes it treat a
Michal Soltys wrote:
Shivkumar Venkatasubrahmanyam wrote:
Hi,
I'm not sure if this is a bug, but after reading the manual, this
does not seem like expected behavior. I'm using the following rsync
command to approximate an atomic update (I can't use --link-dest as
hard links in hfsplus
Shivkumar Venkatasubrahmanyam wrote:
Hi,
I'm not sure if this is a bug, but after reading the manual, this does
not seem like expected behavior. I'm using the following rsync command
to approximate an atomic update (I can't use --link-dest as hard links
in hfsplus filesystems are fubar
Hi,
I'm not sure if this is a bug, but after reading the manual, this does
not seem like expected behavior. I'm using the following rsync command
to approximate an atomic update (I can't use --link-dest as hard links
in hfsplus filesystems are fubar under linux as of 2.6.27):
rsync -a
