Displaying 20 results from an estimated 1000 matches similar to: "Rsync Hangs 100% of the time when copying files from win2k machin es to linux"
2011 Dec 16
1
[Bug 8665] New: Crash in free_xattr(), from recv_generator()
https://bugzilla.samba.org/show_bug.cgi?id=8665
Summary: Crash in free_xattr(), from recv_generator()
Product: rsync
Version: 3.1.0
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
ReportedBy: chris at onthe.net.au
2004 Jul 11
0
[PATCH] [TRIVIAL] whitespace + variable rename
The attached patch adds some whitespace to the recv_files() function
declaration, and renames variable 'f' to 'f_out' in generate_files().
-------------- next part --------------
Index: generator.c
===================================================================
RCS file: /cvsroot/rsync/generator.c,v
retrieving revision 1.93
diff -b -c -r1.93 generator.c
*** generator.c 30 Jun
2004 Jan 25
2
scan for first existing hard-link file
Here's a patch that makes rsync try to find an existing file in a group
of hard-linked files so that it doesn't create the first one in the
group from scratch if a later file could be used instead.
Details: I decided to avoid having the code do an extra scan down the
list when we encounter the lead file in the list. This is because it
would be bad to have to do the same scan in the
2012 Jun 05
2
[Bug 8979] New: rsync daemon: High load while skipping hardlinks
https://bugzilla.samba.org/show_bug.cgi?id=8979
Summary: rsync daemon: High load while skipping hardlinks
Product: rsync
Version: 3.0.5
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: core
AssignedTo: wayned at samba.org
ReportedBy: simon.klinkert at
2004 May 29
1
[patch] Filename conversion
Hi,
One feature missing from rsync, and requested on this list before, is
on-the-fly conversion of filename character encoding. For example, I
often need to sync files having Hebrew filenames from a UTF-8 system
(Linux) to an ISO8859-8 system (Cygwin on Windows 2000 using the
non-Unicode Win32 interface). Other circumstances surely abound.
Attached is a patch against rsync 2.6.2 that adds an
2007 May 21
0
Infinite loop on files > 2Gb
I'm using rsync to sync DB files from a FreeBSD box to a Windows XP box under interix. Until today everything was fine but now as
soon as the windows box hits one file which is now greater than 2Gb it goes into an infinite loop in generator.c:sum_sizes_sqroot
The code at fault seems to be:
for (l = len; l >>= 1; b += 2) {}
Here's the stack:
#0 0x00402ae3 in sum_sizes_sqroot
2007 May 27
1
DO NOT REPLY [Bug 4664] New: Infinite loop on files > 2Gb
https://bugzilla.samba.org/show_bug.cgi?id=4664
Summary: Infinite loop on files > 2Gb
Product: rsync
Version: 2.6.9
Platform: Other
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned@samba.org
ReportedBy: steven.hartland@multiplay.co.uk
2004 Feb 09
1
[patch] Add `--link-by-hash' option.
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.
Anyone have an example of an MD4 collision so I can test that case? :)
Patch Summary:
-1 +1 Makefile.in
-0 +304 hashlink.c (new)
2008 Apr 26
1
Bug#477931: rsync: Segfaults syncing the linux kernel archive.
Hi Wayne,
I just got this bug report about rsync 3.0.2 reproducibly crashing,
together with a backtrace and a patch; very helpful :-)
(Please preserve 477931-forwarded@bugs.debian.org in the CC so that you
response is archived in the Debian BTS, thanks.)
Paul Slootman
On Fri 25 Apr 2008, Kurt Roeckx wrote:
> Subject: Bug#477931: rsync: Segfaults syncing the linux kernel archive.
> From:
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
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 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
2004 Dec 07
1
rsync hangs when tunneling... help!
Greetings and salutations, rsync users. I have a problem. I'm hoping that
someone out there could perhaps provide a hand.
I've been trying to transfer large amounts of data (lots of data, lots of
files) via rsync over an encrypted TCP tunnel, but I seem to be continually
getting hangs in the transfers -- things will go along for a bit, and then
just come to a screetching halt. There
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.
2007 Oct 14
3
DO NOT REPLY [Bug 5020] New: hang using RSYNC_CONNECT_PROG
https://bugzilla.samba.org/show_bug.cgi?id=5020
Summary: hang using RSYNC_CONNECT_PROG
Product: rsync
Version: 3.0.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: wayned@samba.org
ReportedBy: Matt_Domsch@dell.com
QAContact:
2005 Jan 05
1
rsync filename heuristics
On 5 Jan 2005, Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Tue, 2005-01-04 at 18:24 +0100, Robert Lemmen wrote:
> > hi rusty,
> >
> > i read on some webpage about rsync and debian that you wrote a patch to
> > rsync that let's it uses heuristics when deciding which local file to
> > use. could you tell me whether this is planned to be included in
2002 Aug 05
5
[patch] read-devices
Greetings,
I'd like to propose a new option to rsync, which causes it to read
device files as if they were regular files. This includes pipes,
character devices and block devices (I'm not sure about sockets). The
main motivation is cases where you need to synchronize a large amount of
data that is not available as regular files, as in the following scenarios:
* Keep a copy of a block
2013 Dec 01
0
[PATCH v2 4/4] efi: PE file size differ from in-memory size
PE headers code_sz and image_sz indicate more or less, the size of the
file and the size of the in-memory image. They are now given the right
value.
In the ELF format, only the program headers are reliable to determine
the actually needed part of the file and the in-memory size.
The .bss section should always be marked as NOLOAD for ld since its
content shouldn't be included into the binary
2003 Mar 30
1
[RFC][patch] dynamic rolling block and sum sizes II
Mark II of the patch set.
The first patch (dynsumlen2.patch) increments the protocol
version to support per-file dynamic block checksum sizes.
It is a prerequisite for varsumlen2.patch.
varsumlen2.patch implements per-file dynamic block and checksum
sizes.
The current block size calculation only applies to files
between 7MB and 160MB setting the block size to 1/10,0000 of
the file length for a