Franc Carter wrote:
> >Unfortunately, yes.
> Shouldn't that be caught by the fact that the source file has a new
> (or at least different) time stamp now?
>
>Sorry, I should have given a clearer example.
>All in one second
>1. a process modifies the file and h
On 11/1/07, Fabian Cenedese <[EMAIL PROTECTED]> wrote:
>
> At 23:09 31.10.2007 -0400, Matt McCutchen wrote:
> >On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote:
> >> If am rsyncing a file and I have the the following sequence of events
> >> happen in
> >> the same second
> >>
> >>1. rsync
On 11/1/07, Matt McCutchen <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote:
> > If am rsyncing a file and I have the the following sequence of events
> > happen in
> > the same second
> >
> >1. rsync starts
> >2. rsync sends some chunk of data to the oth
At 23:09 31.10.2007 -0400, Matt McCutchen wrote:
>On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote:
>> If am rsyncing a file and I have the the following sequence of events
>> happen in
>> the same second
>>
>>1. rsync starts
>>2. rsync sends some chunk of data to the other end
>>
On Thu, 2007-11-01 at 10:35 +1000, Franc Carter wrote:
> If am rsyncing a file and I have the the following sequence of events
> happen in
> the same second
>
>1. rsync starts
>2. rsync sends some chunk of data to the other end
>3 a local process modifies the chunk that has just been s
Flames/Cluestick invited if I've got this wrong.
I would expect:
rsync checks blocks on source to see if they are the same.
blocks which seemed to be the same (past tense) are not sent.
blocks which seemed to be different will be sent with whatever the current
content of the block happens to be.
t