Displaying 20 results from an estimated 1000 matches similar to: "patch for better handling of write failures (disk full)"
2003 May 23
1
PATCH: better handling for write failures (disk full)
[I sent this the other day, but it never got approved for the list]
I've been having problems trying to sync two small partitions (128MB)
that are usually near being full. The rsync would fail with this
cryptic error:
rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown": Broken pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(515)
It ends up
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
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
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
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 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 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
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
2004 Jun 17
1
[PATCH] make write_batch local
Wayne,
It's taken a little while for me to get more familiar with the
code, but I think I've reached a good breakpoint in improving
batch-mode. Let me highlight some of the changes in the
attached patch:
* --write-batch and --read-batch arguments are no longer passed
from client to server. This fixes the current problem
that causes the server threads to die when the client
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)
2001 Nov 13
2
direct write patch
I have attached a patch that supports a new "--direct-write" option.
The result of using this option is to write directly to the destination
files, instead of a temporary file first.
The reason this patch is needed is for rsyncing to a device where the
device is full or nearly full.
Say that I am writing to a device that has 1 Meg free, and a 2 meg file
on that device is out of date.
2002 Feb 01
0
rsync Warning: unexpected read size of 0 in map_ptr
On Wed, Jan 30, 2002 at 06:03:10PM -0500, Bill Nottingham wrote:
> Dave Dykstra (dwd@bell-labs.com) said:
> > I stumbled across the bug report
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=58878
> >
> > which shows that you made a bug fix to rsync on Sunday. What exactly did
> > you do?
>
> Attached. It's the same thing as yours, I just
2002 Nov 07
0
Bogus rsync "Success" message when out of disk space
To the rsync maintainers:
When rsync 2.5.5 is pulling files and the target disk runs out of space,
this is what the tail end of the message stream looks like (w/--verbose):
write failed on games/ghostmaster/ectsdemo2002.zip : Success
rsync error: error in file IO (code 11) at receiver.c(243)
rsync: connection unexpectedly closed (152112 bytes read so far)
rsync error: error in rsync protocol
2004 Jul 12
2
[PATCH] Batch-mode rewrite
Wayne,
Please consider the attached patch. This applies to the current
CVS, and is independant of patches/local-batch.diff. As a matter of
fact, I'm sure it would conflict heavily with local-batch.diff.
This version of batch mode has a couple distinguishing features:
Write-batch records (almost) the entire sender side of the conversation
into one file. ("Almost" because it has
2003 Apr 27
4
Bogus rsync "Success" message when out of disk space
Patches welcome, eh, Paul?
Upon further (belated) investigation, there are 2 affected places
in receiver.c with this error message. Both call write_file().
And write_file is called only in those two places. So that is the
appropriate location to patch. Especially since the obvious fix is
to use the rewrite code already there for the sparse file writes.
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
2002 Feb 11
0
RSYNC 2.5.2 type mismatches in batch.c
Platform: OpenVMS Alpha 7.3
Compiler: Compaq C T6.5-002 on OpenVMS Alpha V7.3
Comile flags: /WARN=ENABLE=(LEVEL4, QUESTCODE)
Best guess at UNIX equivalents of above compile flags:
LEVEL4 = All warnings
QUESTCODE = Do LINT processing on source.
-John
wb8tyw@qsl.network
Personal Opinion Only
batch.c
(char *) is being used as a type, when a generic structure is being passed.
(void *) appears
2002 Dec 09
2
Rsync performance increase through buffering
I've been studying the read and write buffering in rsync and it turns
out most I/O is done just a couple of bytes at a time. This means there
are lots of system calls, and also most network traffic comprises lots
of small packets. The behavior is most extreme when sending/receiving
file deltas of identical files.
The main case where I/O is buffered is writes from the server (when
io
2003 Jul 24
0
(no subject)
Here is a diff which should allow applying batch updates remotely ( as
apposed to copying the batch files to the remote server and running rsync
there ).
Eg
rsync --write-batch=test src dst1::dst
rsync --read-batch=test dst2::dst
Oli Dewdney
diff -E -B -c -r rsync-2.5.6/flist.c rsync-2.5.6-remotebatch/flist.c
*** rsync-2.5.6/flist.c Sat Jan 18 18:00:23 2003
---