Folks,
We faced a similar situation to that which Ken described - we recycle
backup directories, for good reason.
There is a patch to solve the problem.
Our systems administrator provided the following description of the
patches we use:
==
Hi folks,
This is a patch for rsync 2.6.9 - I'm not sure if this is the proper vehicle
for submitting them. It's been working great for us for months, and I hope
it's seen as offering useful utility in general.
Steve (who is not a subscriber to this list)
---
Stephen J Fr
On Sat, Jan 31, 2004 at 11:39:11PM +1100, Travis Freeland wrote:
>
> G'day,
>
> I figured some others might benefit from this patch. It allows you to use
> the samba style @netgroup names in hosts allow and hosts deny.
>
> I've tested it on solaris and linux with no apparent problems..
>
> I'l
G'day,
I figured some others might benefit from this patch. It allows you to use
the samba style @netgroup names in hosts allow and hosts deny.
I've tested it on solaris and linux with no apparent problems..
I'll get rid of the static string in a couple of days when I have to worry
about tryin
No one else has done anything about this.
This doesn't quite look right to me. The structure we need
to actually use HAVE_SOCKADDR_LEN for is type sockaddr_in,
not sockaddr. Further, the members of sockaddr appear to
have sa_ prefixes. Only sockaddr_in members have the sin_
prefix. So either we
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
> > Is there any reason why caching programs would need to set the
> > value, rather than it just being a fixed value?
> > I think it is hard to describe what this is for and what it should be
> > set to. Maybe a --fixed-checksum-seed
On Sun, Jan 26, 2003 at 06:04:52PM -0800, Craig Barratt wrote:
> > Block checksums come from the receiver so cached block
> > checksums are only useful when sending to a server which had
> > better know it has block checksums cached.
>
> The first statement is true (block checksums come from the r
> Block checksums come from the receiver so cached block
> checksums are only useful when sending to a server which had
> better know it has block checksums cached.
The first statement is true (block checksums come from the receiver),
but the second doesn't follow. I need to cover the case where
On Sun, Jan 26, 2003 at 02:46:43PM -0800, Craig Barratt wrote:
> > Is there any reason why caching programs would need to set the
> > value, rather than it just being a fixed value?
> > I think it is hard to describe what this is for and what it should be
> > set to. Maybe a --fixed-checksum-seed
> Is there any reason why caching programs would need to set the
> value, rather than it just being a fixed value?
> I think it is hard to describe what this is for and what it should be
> set to. Maybe a --fixed-checksum-seed option would make some sense,
> or for a caching mechanism to be built
Is there any reason why caching programs would need to set the
value, rather than it just being a fixed value? I think it is hard
to describe what this is for and what it should be set to. Maybe a
--fixed-checksum-seed option would make some sense, or for a caching
mechanism to be built in to rsy
Harald Fielker wrote:
> Am Samstag, 18. Januar 2003 22:54 schrieb Max Bowsher:
>> Green, Paul wrote:
>>> You might consider using zlib instead of gzip; same algorithm, same
>>> author, but you can access the compression code via a subroutine
>
> Do you have an idea how i can use it for compressing
Am Samstag, 18. Januar 2003 22:54 schrieb Max Bowsher:
Hi,
> Green, Paul wrote:
> > Harald,
> >
> > You might consider using zlib instead of gzip; same algorithm, same
> > author, but you can access the compression code via a subroutine
Do you have an idea how i can use it for compressing a whol
Green, Paul wrote:
> Harald,
>
> You might consider using zlib instead of gzip; same algorithm, same
> author, but you can access the compression code via a subroutine
> interface. You would not have to spawn another process to run gzip,
> and you would not be dependent upon the user having gzip in
Harald,
You might consider using zlib instead of gzip; same algorithm, same author,
but you can access the compression code via a subroutine interface. You
would not have to spawn another process to run gzip, and you would not be
dependent upon the user having gzip installed.
It is not covered by
Hi,
i finished my storage compression patch for rsync.
WARNING - THIS IS ONLY FOR TESTING!
How does this work?
Just add a "-Z" option to your common rsync commandline parameters. The
destination files will be stored in a compressed way (by using a hardwired
call of gzip).
This wor
> While the idea of rsyncing with compression is mildly
> attractive i can't say i care for the new compression
> format. It would be better just to use the standard gzip or
> other format. If you are going to create a new file type
> you could at least discuss storing the blocksums in it so
> th
On Wed, Jan 15, 2003 at 03:23:19AM -0800, you [jw schultz] wrote:
> On Wed, Jan 15, 2003 at 11:50:27AM +0100, Harald Fielker wrote:
> > Hi,
> >
> > i am using Rsync for making backups of a MySQL database. The MySQL files can
> > be compressed about 1:10 and i want to make use of this fact.
> >
>
On Wed, Jan 15, 2003 at 11:50:27AM +0100, Harald Fielker wrote:
> Hi,
>
> i am using Rsync for making backups of a MySQL database. The MySQL files can
> be compressed about 1:10 and i want to make use of this fact.
>
> Rsync currently doesn't support saving files in a compressed state. I
> pers
Hi,
i am using Rsync for making backups of a MySQL database. The MySQL files can
be compressed about 1:10 and i want to make use of this fact.
Rsync currently doesn't support saving files in a compressed state. I
personally think this should be a feature for the filesystem (in the sense of
"sy
On Tue, Sep 03, 2002 at 05:00:02PM -0700, [EMAIL PROTECTED] wrote:
>
> JW,
>
> I pushed everything to a LINUX box and did the diff again this time with the
> -bur option.
> It does look significantly different. I think I've got below what you are
> looking for, so I am
> resending it to [EMAIL
JW,
I pushed everything to a LINUX box and did the diff again this time with the
-bur option.
It does look significantly different. I think I've got below what you are
looking for, so I am
resending it to [EMAIL PROTECTED]
I'm including two additional people as they have asked for the patch in
Dave:
I don't suppose you could upload this as a context diff? ("diff -c ") My patch program (2.5.4) couldn't get it to apply vs. the current CVS version
of rsync.
-- Steve
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www
To Whom It May Concern:
Below is a patch, that I have used to eliminate the unexplained
errors in the rsync program. I was able to trace the problem to
the order in which the sigchld_handler and wait_process routines
were executed. If sigchld_handler executes first it retrieves
the status that
Eckebrecht von Pappenheim wrote:
>
> Hi,
>
> we used 'mirror' for a while, and it sucks. So we switched to rsync.
>
> But one feature we missed (maybe we didn't find it): mirror has a
> parameter 'get_size_change', which, if set to false, tells it to ignore
> file size changes and look only for
Hi,
we used 'mirror' for a while, and it sucks. So we switched to rsync.
But one feature we missed (maybe we didn't find it): mirror has a
parameter 'get_size_change', which, if set to false, tells it to ignore
file size changes and look only for changes of modification time.
Attached you'll fi
26 matches
Mail list logo
