similar to: [Bug 2409] New: rsync doesn't handle directories changing into symlinks well

Please see the included debian bug report, where during a local transfer rsync (3.0.3) follows a symlink in the destination to delete a file in the source tree. At least 3.0.5 works correctly in this regard; however I can't find a changelog entry that's directly related to this. Would it be possible to extract the diff that fixes this so that the 3.0.3 version in debian stable might be

Hi, sorry if this is old stuff, but I did my best to look first... Have been getting errors along these lines: mv mydir mdir.2002 ln -s mydir.2002 mydir Then update mirror with rsync -av --delete-after. Without --delete-after, no problem, with --delete-after, get a code 23. The attached shell script will recreate the error (on my machine, at any rate). Just run it from a clean directory.

Hello, I'm backing up a file server using rsync from a cron job, which recently started to give me errors like: delete_file: rmdir "/some/path" failed: Directory not empty symlink "/some/path" -> "/some/other/path" failed: File exists Looking at the involved files and directories, it looks like the user decided to replace a directory with a symlink, but

Regarding "rsync error code 23" could the below "delete_file: ...file exist" failures cause the error code 23? Or, how can I resolve this as these are the only errors I see in the log files. Thank you! START Tue Aug 26 11:10:12 PDT 2008 /home/filerep/bin/rsync -e /var/openssh/bin/ssh --archive --stats --timeout 3600 fmttcesrv1::tce_data

I'm trying to switch to using rsync for updating a huge software library containing binaries, text files, symlinks, and so on. We've been using something homegrown which I'm not that happy with - it's a perl script that systems cp and chmod and such. The problem I'm seeing is: target computer: directories ctime-5 and ctime-5b3 are distinct directories source computer:

Hello, I think I found a bug in rsync. I checked the TODO and the issues, but I didn't find any reference to it. It seems, that rsync goofes up, if you rename a directory and then create a symlink with the old name to the new location. Below is a simple example how to do it. ------------------------------------------------------------------------------ [ptriller] elmore:~/test > ls

Hi, the combination of --keep-dirlinks and --delete (--delete-during, --delete-delay) erroneously deletes symlinks to directories on the receiver. With --delete-before and --delete-after it works as expected. (rsync version 3.0.3 protocol version, on Debian Lenny) I don't think that this behaviour is intended. Details/example: - Host 1 directory-structure: drwx------ ./1

Good day, all, I'm using rsync 2.5.4 and a statically linked version of 2.5.5 to back up my main system to a backup drive (See rsync-backup at http://www.stearns.org/rsync-backup/ ). First, I made a full backup of the system. Then, on the main system, I merged the articles in techdocs to another directory called articles, removed the techdocs directory and made it a symlink to the

https://bugzilla.samba.org/show_bug.cgi?id=6240 Summary: rsync 3.0.x -x/--one-file-system regression? Product: rsync Version: 3.0.5 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: mej@lbl.gov

Hourly I have an rsync job backup /home to /home/backup. I have 24 directories (one for each hour): home.0 ... home.23 Here is the script I am running via cron: #! /usr/local/bin/bash dest=`date +%k | sed 's/ //g'` linkdir=`date -v-1H +%k | sed 's/ //g'` chflags -R noschg /home/backup rm -rf /home/backup/home.$dest rsync -ahHP --numeric-ids --delete --stats --link-dest=../

Hello list. I've got following: rsync: opendir "client05" (in Profili) failed: Permission denied (13) rsync: delete_file: rmdir(client02/SendTo) failed: Permission denied (13) Am I correct if I say that the "opendir" is related to the source I'm trying to rsync, but the "delete_file" is related to the destination? Flavio Boniforti PIRAMIDE INFORMATICA

Hi, How about adding now option '--backup-only' that means making backups only and don't change any destination files? (I posted similar patch a month ago, but the patch was made for nightly snapshot of 20020808, which was tooo old! Laugh at me...) I want to use rsync with LVM snapshot to make incremental backups like below: 1) Make LVM snapshot of file system and mount it.

Hi, as documented, if you use rsync with --copy-unsafe-links, and copy a directory with a symlink pointing outside of the copied tree, the referent of the symlink is copied. Now, assume that the directory contains a symlink, which points to a (2nd) directory outside of the copied tree. If this (2nd) directory contains another symlink, which also points outside of the copied tree, rsync

https://bugzilla.samba.org/show_bug.cgi?id=1673 Summary: Verbose dry run doesn't report replacements of symlink with directory Product: rsync Version: 2.6.2 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org

There appears to be a problem with the handling of symlinks within source directories by the --relative (-R) option. I am using rsync 2.5.5 on an SGI Origin 200 running IRIX 6.5.11f. Example: copying the contents of /usr/local/etc/inhouse/db/ from wolf to fox where /usr/local is a directory on wolf, but /usr/local is a link to /usr2/local on fox. Here's the dry-run output (some

hello- i am using rsync via ssh to maintain a copy of a few directories on a remote server, and am getting an error when rsync tries to chmod a certain file following it's transfer. there are a couple of cases in which this occurring - below is one example. local machine is debian testing - rsync version 2.6.3 protocol version 28 remote machine is macos x 10.3.7 - rsync version 2.6.2

https://bugzilla.samba.org/show_bug.cgi?id=11668 Bug ID: 11668 Summary: incorrect/inconsistent behavior when --backup-dir is on a full filesystem Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core

Hi all, I have rsync'ed directory /rootdir/dirdir/ from Server1 to Server2, using cmd on Server2 "rsync Server1:/rootdir/dirdir -avz /rootdir/dirdir". There were some sub-directories from Server1 got updated to become the symbolic links. For example, directory /rootdir/dirdir/subdir1/ now becomes the symbolic link /rootdir/dirdir/subdir1 pointing to the new created directory

https://bugzilla.samba.org/show_bug.cgi?id=3935 Summary: replacing a full directory with symlink with --delete- after produces cryptic message Product: rsync Version: 2.6.6 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

Hi list, I would like to know if the following rsync's behavior can be changed/modified. I noticed that when rsync receive a file for which the local filesystem already has a symlinks with the same path/name, it _first_ delete the symlink, _then_ it start the transfer. I think there are two problems with this approach: - it completely ignores the content of the symlinked files, which can