On Tue, May 30, 2023 at 02:10:31PM +, Job Snijders wrote:
> On Tue, May 30, 2023 at 03:12:46PM +0200, Claudio Jeker wrote:
> > On Tue, May 30, 2023 at 02:38:23PM +0200, Claudio Jeker wrote:
> > > On Wed, May 24, 2023 at 04:18:30PM +, Job Snijders wrote:
> > > > Dear all,
> > > >
> > > > Cl
On Tue, May 30, 2023 at 03:12:46PM +0200, Claudio Jeker wrote:
> On Tue, May 30, 2023 at 02:38:23PM +0200, Claudio Jeker wrote:
> > On Wed, May 24, 2023 at 04:18:30PM +, Job Snijders wrote:
> > > Dear all,
> > >
> > > Claudio made some suggestions to pass the desired modification times
> > > a
On Tue, May 30, 2023 at 02:38:23PM +0200, Claudio Jeker wrote:
> On Wed, May 24, 2023 at 04:18:30PM +, Job Snijders wrote:
> > Dear all,
> >
> > Claudio made some suggestions to pass the desired modification times
> > around in a different way, below is an updated patch proposal.
> > I also ad
On Wed, May 24, 2023 at 04:18:30PM +, Job Snijders wrote:
> Dear all,
>
> Claudio made some suggestions to pass the desired modification times
> around in a different way, below is an updated patch proposal.
> I also added some instrumentation to also adjust GBRs and TAKs.
>
> RIPE & APNIC in
Dear all,
Claudio made some suggestions to pass the desired modification times
around in a different way, below is an updated patch proposal.
I also added some instrumentation to also adjust GBRs and TAKs.
RIPE & APNIC informally indicated some interest in this hack.
Kind regards,
Job
Index: e
Dear all, Claudio,
A series of RRDP outages around the world prompted me to study whether
the subsequent (perhaps even first-ever) RSYNC synchronization can be
optimised for both client and rsync server.
In the RSYNC protocol a file's last modification time and its size are
used to determine whet
