similar to: [PATCH] docs: XenBus page has been transfered to new wiki

I've run into a bug in the IO handling when reading a file. Suppose I have a file that lives on an NFS filesystem. That filesystem is NOT being exported with auth=0 permissions. So, if I try to access a file as root, it successfully opens the file, but subsequent reads fail with EACCES. This produces a destination file full of null bytes. I noticed this with 2.5.7, but checked 2.6.2 as

There is a small race condition in rsync 2.5.6. When the transfer is finished, and the file is moved into place, there is a short time period where the new file is in place with the wrong permissions. When using rsync on a busy email server to replace the exim config file with a new file, exim will produce several complaints in that short period. This small patch fixes the problem, by making

As I reported a while back rsync doesn't handle metadata (permissions and ownership) in dryrun mode. I offered to make a patch and that offer still stands. I didn't have the time for it until now and want to pick it up again. I had some ugly hack back then but I want to redo it in a clean way. I would like some input on my thoughts. IMHO, it would be ideally if the check for dry_run

Hi, Is there a way to change the permission for a specific path in XenStore? And can you do that from with in a C program? Thanks Julian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

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 again. I just spotted another peculiarity when inspecting the rsync log. When using --compare-dest, source files that have permissions that differ from the "comparables" are not logged, unless you're using -i. Here's a testing session: $ ls -lR .: total 12 drwxr-xr-x 2 vidar users 4096 2005-03-31 14:16 cmp/ drwxr-xr-x 2 vidar users 4096 2005-03-31 14:23 dst/

I've rebased the patch series to the current next branch and am sending them again.

I am running RedHat 6.2 on many of my servers and am receiving the following errors when compiling Rsync 2.5.2: [root@wrapguy rsync-2.5.2]# make gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c rsync.c -o rsync.o In file included from rsync.c:23: rsync.h:339: warning: no semicolon at end of struct or union rsync.h:339: parse error before `inode' rsync.h:341: parse error before `dev'

Has anybody seen this? We want to seperate the statistics out from the file list, and were using tail to grab the end of the file. the command we run is: rsync -r -a -z --partial --suffix=".backup" --exclude="*.backup" \ --stats -v /. 10.1.1.60::cds101/ > /var/log/rsync.log 2>&1 along with a number of excludes to skip the /tmp, /dev,

We use rsync to update an nfs server. After an update, we noticed that a large number of clients didn't see the updated data. It took me a while to be able to reliably reproduce this problem, but it happens on old and new versions of rysnc. It also happens across all the platforms we use here (sun/linux/netapp). This shows the problem: [Note my home directory is NFS mounted]

Does the --backup, --backup-dir set require that either then source or target be a remote connection? Test folder hierarchy: /Users/localskaiser/source/myfile.txt /Users/localskaiser/source/a/b/c/newfile.txt /Users/localskaiser/target /Users/localskaiser/archive I can not get the following command to work (after running it once, and then modifying newfile.txt): [skaiser-pbg4:~] localska%

https://bugzilla.samba.org/show_bug.cgi?id=2913 ------- Additional Comments From wayned@samba.org 2005-07-26 09:27 ------- Created an attachment (id=1336) --> (https://bugzilla.samba.org/attachment.cgi?id=1336&action=view) Use lchmod and lutimes, if present Please test this patch and see if it works for you. You will need to run "autoconf; autoheader; make proto" (or

Hello, i'm using rsync 2.6.0 for daily-syncing some remote AIX 5.2 machine to a local linux (RH 7.3) with using the --link-dest option for saving space on incremental backups. Even if there are no changes on the AIX machine, all files are newly transferred on every new sync. My test scenario (actisi=remote aix machine, actisa=local linux machine): =====> Initial rsync [mma@actisa

[This email is either empty or too large to be displayed at this time]

I came up with a patch to fix the problem of IO Errors caused by excluded files as did Eugene V. Chupriyanov below. Is there a chance that this change will show up in a future version of rsync? Is there a reason that we should not ignore IO errors when copy_links is off? Just want to make sure that I'm not missing something here that may corrupt my syncs.... Here's the version that

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

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 had a friend run some Cygwin tests and we found that --modify-window=1 works just as well as --modify-window=2 on FAT filesystems to copy files from Unix and detect the difference in granularity. FAT filesystems always have timestamps that have an even number of seconds. On the other hand, NTFS filesystems can store the modification time down to the second, whereas previously people on this

The attached patch adds support for simple waiting for a watched key to change to a certain value. This patch is necessary for the netfront driver (separate patch). regards, Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch ports the Linux implementation of xenbus, in order to do that very simple threading support is introduced. Apart of that numerous fixes for 64 bit are included. Mini-os now compiles (for 64bit) but requires memory management and threading fixes before it works as well as 32bit version. Gregor _______________________________________________ Xen-devel mailing list