similar to: when using --backup-dir: why not make_bak_dir() . . .

Running rsync 2.4.7pre1, using the --backup-dir option, I just realized today that file ownerships and permissions of backed up files are not preserved. In other words, if rsync moves an obsolete file to the backup dir, it's ownership seems to revert to root:root, and permissions change, as well. We are also using the -a (archive) option, by the way, which should mean "preserve

Yesterday I upgraded rsync from 2.6.9 to 3.0.2 (as part of upgrading Fedora 8 to Fedora 9). Today, I received these unexpected errors: rsync: make_bak_dir mkdir "/backup/server/../server-before-5/var" failed: File exists (17) rsync: keep_backup failed: "/backup/server/var/lib/rpcbind/rpcbind.file" -> "../server-before-5/var/lib/rpcbind/rpcbind.file": Success (0)

I have users running rsync 3.0.6 on Mac OS 10.5 and 10.6 with the following arguments (for example): rsync -aNHAXx --fileflags --force-change --no-inc-recursive --delete-during --filter="P _Archive*" --filter="P /*" --backup --backup-dir="_Archive_2010_March_07_22-27-43" / /Volumes/Backup I can't seem to figure out how make_bak_dir could be returning this error

Rare and intermittent message groups suggest a race condition ... ? Here's the pattern of messages: rsync: make_bak_dir mkdir <path> failed: File exists (17) rsync: keep_backup failed: <path> -> <path>: No such file or directory (2) rsync: stat <path> failed: No such file or directory (2) How rarely? We run a scripted rsync daily on ~50 personal computers and

All callers of robust_rename() call copy_file() if EXDEV is received. This patch moves the copy_file() call into robust_rename(). Patch Summary: -12 +1 backup.c -15 +2 rsync.c -9 +33 util.c -------------- next part -------------- patchwork diff util.c --- util.c 2004-02-17 09:58:44.000000000 -0500 +++ util.c 2004-02-17 10:21:22.000000000 -0500 @@ -355,16 +355,40 @@

Hi: Suppose I have the following files on my target volume: /Applications/[45,000 sub files and directories] /Developer/[120,000 sub files and directories] ... (another 8 or so directories with lots of files and sub directories) /usr/ [75,000 sub files and directories] For a total of approximately 500K files and directories. On my source, I have only a handful of items: /Data/ [70 items]

Hello, I've been porting rsync-3.0.7 to run on UWIN, an AT&T Labs open source project, supporting a Unix environment on Windows. The code configured easily and compiled without any modifications or ifdef's added to the code. The backup test was failing because it didn't create a subdirectory. In tracing the code I realized the problem was in robust_move() in backup.c. UWIN returns

Through several versions up to and including the current 3.0.9 I experience sporadic, repeating (but not predictably) errors of this form: > rsync: make_bak_dir mkdir "/REPO/backup/XXXX-data1-20120727-040453" failed: File exists (17) > rsync: keep_backup failed: "/REPO/backup/XXXX-data1/data1/A182/tb5178/tb5178.hebb/out.TENT_warn.txt" ->

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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear list members, there are two new rsync-features I made up and would like to discuss with you. If you think these new features might be useful for the whole rsync-community, please give me a note and I'll send you the patches (or post them here). 1.) Setting owner and/or group of backup files. In our servers I'm using rsync to backup

As those of you who watch CVS will be aware Wayne has been making progress in reducing memory requirements of rsync. Much of what he has done has been the product of discussions between he and myself that started a month ago with John Van Essen. Most recently Wayne has changed how the file_struct and its associated data are allocated, eliminating the string areas. Most of these changes have been

I tried rsync 2.6.1cvs on my FreeBSD 4.X boxes. It dumps core when preserve_hard_links and backup. And SUPPORT_HARD_LINKS is true. rsync -avH --delete --backup --backup-dir=/some/backup/dir \ srchost::dir/ dir/ The core says... ------------------------------------------------------------------------ Program terminated with signal 11, Segmentation fault. #0 0x80536c0 in keep_backup

Included below is a shar archive containing two patches that together: 1) make backup files get their setuid and setgid bits stripped by default 2) add a "-s" option that allows backup files to continue to have these privileges This means that if you update a collection of binaries with rsync, and one or more of them has a local-root security problem, the backup file(s) created when

I am try to use rsync from my windows box (under cygwin) to back up "My Documents" on to a debian server (known on my home network as roo.home) running rsyncd from inetd where it is run as root. my rsyncd.conf file sets the gid and uid to user backup.backup thusly:- syslog facility = daemon uid = backup gid = backup hosts allow = 192.168.0.0/24 hosts deny = 0.0.0.0/0 timeout = 600

Hello, I suspect a minor bug in the file rsync-2.5.4/backup.c line 206. To identify too-long pathnames, it makes the following test: if (strlen(backup_dir) + strlen(fname) > (MAXPATHLEN - 1)) I think that the constant subtracted off should be 2, to account both for the forward-slash and for the trailing zero in the following snprintf statement, line 211: snprintf(keep_name, sizeof

Hello everybody, this is a reply to the discussion found at: http://comments.gmane.org/gmane.network.rsync.general/22018) I still get this error from time to time, so I suppose it is not fixed in version 3.0.9. Just downloaded the patch and recompiled will test the next days. Is there a bug report for this in bugzilla? Could not find anything. -- Best regards, Chris

https://bugzilla.samba.org/show_bug.cgi?id=2758 Summary: "File exists" error using options -b and --backup-dir with device files. Product: rsync Version: 2.6.4 Platform: All OS/Version: AIX Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

When I perform a rsync with backup I get 100's of: make_bak_dir mkdir "/export/giger.back.....eary/java/weka/gui" failed: File exists make_bak_dir mkdir "/export/giger.back....ary/java/weka/gui" failed: File exists make_bak_dir mkdir "/export/giger.back...ary/java/weka/gui" failed: File exists . . . My backup command is: rsync -q --backup

Hello, I use rsync for incrmental backups in the following way: rsync \ $EXCLUDE \ -e ssh \ --archive \ --numeric-ids \ --compress \ --relative \ --one-file-system \ --cvs-exclude \ --delete \ --delete-excluded \ --bwlimit=0 \ --backup \ --suffix='' \ --backup-dir=$BACKUP_ROOT/$BACKUP_HOST/${TODAY} \ $BACKUP_HOST_AND_PATH

Hi All, I think I am missing something with the backup-dir-dels.diff patch. How does that differ from the original --backup -backup-dir=DIR option? Using the original one works fine (on patched or non-patched rsync), putting deleted source files into the DIR on destination, but when I run --backup -backup-dir-dels=DIR, nothing happens to the deleted files. Rob D