Displaying 20 results from an estimated 700 matches similar to: "DO NOT REPLY [Bug 5820] New: rsync does not replace symlink atomically"
2008 May 08
1
Patch to not modify files in place unless "--inplace" option specified
Skipped content of type multipart/alternative-------------- next part --------------
diff -urN rsync-3.0.2-orig/generator.c rsync-3.0.2/generator.c
--- rsync-3.0.2-orig/generator.c 2008-03-28 10:30:11.000000000 -0700
+++ rsync-3.0.2/generator.c 2008-05-07 15:35:08.317364774 -0700
@@ -1508,6 +1508,7 @@
if (preserve_links && S_ISLNK(file->mode)) {
#ifdef SUPPORT_LINKS
+ int iflags =
2009 Mar 11
0
Odd issue with locked directories and Mac OS X
Some of my users have reported problems with rsync puking on locked
folders. The errors typically look like this:
rsync -aNHAXx --fileflags --force-change --no-inc-recursive / /Volumes/
Backup
> rsync: mkstemp "/Volumes/SCSI Backup/Users/Ken/Library/Caches/
> Metadata/Safari/Bookmarks/..DS_Store.N9xtNy" failed: Operation not
> permitted (1) (51)
> rsync: mkstemp
2009 Oct 15
1
PATCH: --write-devices to allow synchronising to a block device
Hi List,
I had a need recently to efficiently synchronise between some large LUNs
(boot drive disks) at two different datacentres. Solutions like drbd and
$proprietary_array_vendors_software were overkill - we only needed
(wanted!) to periodically synchronise these LUNs whenever major changes
were generated on the source. On the other hand however, re-sending the
entire disk contents each time
2004 Apr 27
1
[PATCH] Inplace option for rsync
Hi,
I have written a 'smallish' patch to implement the --inplace option
as discussed on this mailing list at various points in the past. It
makes a small modification to the sender algorithm so that it won't ask
the receiver to relocate blocks from earlier in the file when running
with the --inplace option.
I would appreciate any testing and feedback people can provide! I
2004 Feb 17
0
[patch] Add `--link-by-hash' option (rev 3).
This patch adds the --link-by-hash=DIR option, which hard links received
files in a link farm arranged by MD4 file hash. The result is that the system
will only store one copy of the unique contents of each file, regardless of
the file's name.
(rev 3)
* Don't link empty files.
* Roll over to new file when filesystem maximum link count is reached.
* If link fails for another reason, leave
2004 Feb 23
0
[patch] Add `--link-by-hash' option (rev 5).
This patch adds the --link-by-hash=DIR option, which hard links received
files in a link farm arranged by MD4 file hash. The result is that the system
will only store one copy of the unique contents of each file, regardless of
the file's name.
(rev 5)
* Fixed silly logic error.
(rev 4)
* Updated for committed robust_rename() patch, other changes in CVS.
(rev 3)
* Don't link empty
2004 Feb 23
0
[patch] Add `--link-by-hash' option (rev 4).
This patch adds the --link-by-hash=DIR option, which hard links received
files in a link farm arranged by MD4 file hash. The result is that the system
will only store one copy of the unique contents of each file, regardless of
the file's name.
(rev 4)
* Updated for committed robust_rename() patch, other changes in CVS.
(rev 3)
* Don't link empty files.
* Roll over to new file when
2008 Mar 19
0
[PATCH] Unsnarl missing_below/dry_run logic.
The generator can skip a directory's contents altogether due to
--ignore-non-existing, a daemon exclude, or a mkdir failure. On a --dry-run,
the generator can also note the missingness of a directory while still scanning
its contents. These two scenarios were conflated using a single set of
missing_below/missing_dir variables in combination with transient increments in
dry_run; this caused
2004 Feb 17
1
[patch] Make robust_rename() handle EXDEV.
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 @@
2004 Feb 16
1
[patch] Add `--link-by-hash' option (rev 2).
This patch adds the --link-by-hash=DIR option, which hard links received
files in a link farm arranged by MD4 file hash. The result is that the system
will only store one copy of the unique contents of each file, regardless of
the file's name.
(rev 2)
* This revision is actually against CVS HEAD (I didn't realize I was working
from a stale rsync'd CVS).
* Apply permissions after
2006 Oct 21
1
Rsync 2.6.9pre2 tries to read ACLs of nonexistent files
Dear rsync people,
Today I tried to back up my computer using rsnapshot with the RPM
version of rsync-acl 2.6.9pre1 that I built. I tried twice, and both
times, rsync encountered some kind of assertion failure. I was trying
to reproduce the crash with rsync-acl 2.6.9pre2 and noticed a
different bug (described below); when I have a chance, I will go back
and investigate the crash further.
Rsync
2008 Feb 15
4
Revised flags patch
Hi,
first of all, sorry for taking so long. Unfortunately, some other tasks
kept coming up. Anyway, attached is the version of the flags patch, that
is based on the one I'm using with 2.6.9. It is against the rsync-3.0.0pre9
release.
I've included the option name change from the repository, so the
option is now called --fileflags. Improved from the previously
distributed version is the
2011 Feb 24
1
osx 10.6 strange rsync errors
I've recently encountered this issue which was discussed here about a year ago.
I'm not sure if anyone has a fix for this, but I thought I would post my workaround here.
Since the topic is old, I'm summarising the problem .. basically it involves rsync creating large numbers of files with a leading ".." when syncing to an apple network share via afp.
The essence of the
2011 Apr 05
2
osx 10.6 strange rsync errors
Hi Rob / Wayne,
Sorry for the slow reply Rob.
I'm not sure of the requirements for patches, but I think it would be useful to create one for this case as there are reasonably number of people affected.
I created a patch file against the current version (see below).
Would it be possible to include this patch in the official list?
Cheers
Ira
diff -Naur rsync-3.0.8_orig/receiver.c
2005 Jul 26
1
[patch] paranoid checksum checking
The attached patch provides an additional check for the checksumming
mode to ensure that a file that is actually written out to disk can be
read back and has the same MD4 sum as the file on at the originating
location.
Regards,
Nick.
-------------- next part --------------
*** rsync-2.6.6pre1/receiver.c 2005-04-14 02:42:13.000000000 +0100
--- rsync-new/receiver.c 2005-07-26
2007 Sep 22
0
rsync build on IA64 using icc
I got numerous warnings when building rsync on IA64 (Itanium-2) using
Intel C/C++ compiler (see attached). Is this expected? Thanks, Michael
-------------- next part --------------
Script started on Fri 21 Sep 2007 06:14:05 PM BST
~/src$ ls -alt
total 222884
-rw-r--r-- 1 mccssmb2 mcc101 0 Sep 21 18:14 build_rsync
drwxr-xr-x 8 mccssmb2 mcc101 4096 Sep 21 18:14 .
-rw-r--r-- 1
2004 Apr 27
1
rsync-2.6.1 close() fixes
hi.
return value of close() (receiver.c) is ignored.
when running out of quota on NFS (for example),
this can happen (without the patch):
output file(s) is/are truncated to 0 bytes and rsync reports success.
with the fix, this happens:
close "/home/luser/.test.mp3.PwaG50": Disc quota exceeded
rsync error: error in file IO (code 11) at receiver.c(464)
...
...and additionally, test.mp3
2010 Jun 15
3
about rsyncing of block devices
Hiya,
I can see it's a regular subject on this list.
I, like others wanted to use rsync to synchronise two block
devices (as it happens one lvm volume and one nbd device served
by qemu-img on a remote host from a qcow2 disk image so that I
can keep the old versions)
As I couldn't find any report of it being done successfully,
I'm just sharing my findings as it might benefit others.
2009 Mar 11
0
rsyserr is occasionally dropping receiver messages
Typically rsync exits and reports an error such as:
rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken
pipe (32)
rsync: write failed on "/Volumes/Backup/big_file.dmg": No space left
on device (28)
rsync: connection unexpectedly closed (67174 bytes received so far)
[sender]
rsync error: error in rsync protocol data stream (code 12) at /src/
rsync-3.0.5/io.c(600)
2008 Aug 20
0
Problem with exact moment of issuing transfer log entry for a [recv] action
Some background: I have been assigned a task to implement one-way
synchronization of a large file storage to another box. The problem is
that on the target box a special directory has to be maintained in which
symlinks to received files should be created using special logic.
After some experimentation I have set up a named pipe which is used by
the receiving rsync daemon for transfer logging;