Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <000e01c54c15$28c63630$2d00000a@wsmap> From: "Marcus Picasso" To: Subject: Unison 2.10.2 fast update check broken? Date: Thu, 28 Apr 2005 20:10:21 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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 Can somebody confirm / explain this behaviour? I have a large tree that I'm synchronizing across two hard-disks, and got suspicious when re-running synchronization takes longer than expected. The above transcript functions as expected using linux or native Win32 unison builds. Regards, -Marcus. -- 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/