Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <000501c54c2f$4343d520$0100a8c0@wsmap>
From: "Marcus Picasso" <marcus DOT picasso AT kolumbus DOT fi>
To: <cygwin AT cygwin DOT com>
Subject: Re: Unison 2.10.2 fast update check broken?
Date: Thu, 28 Apr 2005 23:17:12 +0300
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

Hi Andrew,

I just rerun the transcript below with both linux and native Win32 builds
of unison, and the difference is, that those versions actually transfer the
modification times even if the content of the file is unchanged. This
results in the following synchronizations to not to have to read the
contents of files, because the modification times match.

So the problem actually is in the Cygwin version, and if you (or somebody)
somehow could get it to transfer the modification times, that would be
great. It probably hasn't got anything to do with your patches, more likely
with Cygwin file modification times (maybe the ctime issues mentioned on
this list?), but maybe a patch for this problem is still possible? Too bad
I don't know oCaml. :)

I'm using unison to backup a large tree to a spare hard-drive, and from
there on to another PC, and noticed that lots of files get reread
unnecessarily at each syncrhonization, which slows it down
considerably. The Cygwin port is valuable, because I have greater control
on the file-permissions of files that get created by unison, and it also
can spawn external processes (which the native one can't), for instance to
do a merge in an editor.

Thanks,
-Marcus.

> Hi Marcus.  Thanks for the report.
>
> > Seems that Cygwin port of the unison file synchronizer does not do the
> > -fastcheck very well. Transcript follows:
> >
> > # Start of transcript
> >
> > # creates archives for first time
> > $ cd /tmp ; touch a b ; /bin/unison-2.10.2 ./a ./b
> > ...
> >
> > $ touch a
> >
> > $ /bin/unison-2.10.2 -fastcheck true -times -debug verbose ./a ./b
> > ...
> >
> > # now output shows that file contents is checked, ie. the "Double-check
> > # possibly updated file" line, which is correct, since we did a touch
> >
> > $ /bin/unison-2.10.2 -fastcheck true -times -debug verbose ./a ./b
> > ...
> >
> > # BUG: outputs again the "Double-check possibly updated file" line for 
> > file
> > # 'b', ie. file content is checked even if no mods.
> >
> > # End of transcript
>
> I think this is the expected behavior, since a and b have the same
> contents.  When Unison observes the different timestamps, it flags the
> files as possibly different and prints the "Double-check" message.  Then
> it looks more carefully, and determines that their contents are in fact
> the same, so no update is propagated.  That includes the timestamps,
> even though you specified -times.  So then when you run the operation
> again, the same thing happens because nothing was changed on the
> previous run.
>
> The effect of -times is to make Unison synchronize the timestamps when
> an update is needed because the file contents are different.  It doesn't
> make the timestamps sufficient to determine that files are different.
> At least, that's my reading of the manual.
>
> > The above transcript functions as
> > expected using linux or native Win32 unison builds.
>
> Hm, are you sure?  If so, then that blows away my carefully constructed
> explanation above.
>
> I've looked at the set of patches that I applied to get Unison 2.10.2
> running in Cygwin, and I don't see anything there that would obviously
> affect the -fastcheck option.  But it's possible, and if you show me the
> evidence I'll look into it.
>
> HTH,
> Andrew. 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/