[Unison-hackers] BugTracker?

[Benjamin C. Pierce]

(Sorry — hit Send too soon…)

Clearly, the best way to solve this problem is to get more accurate mtime information from the OS.  I know that at least some modern Linuxes can give mtimes in nanoseconds, which should really be good enough.  I’m not sure about OSX or Windows.

Another simple way would be to make Unison re-fingerprint each file that it’s transferred (on both source and target sides) after waiting for one second (or two seconds, on FAT32 filesystems) and take appropriate action if things have changed out from under it.

A less simple but perhaps more robust way is:
While reconciling, record the “last synchronized time” for each file in the archive.
On the next sync, if a file’s last sync time is equal to its modtime, then fingerprint it again just to be sure (rather than trusting the “equal mtimes and equal inode numbers” optimization).
Anybody have thoughts about this?  (Either the proposed solutions or the seriousness or not of the basic problem.)

     - B


On Oct 26, 2014, at 12:44 PM, Benjamin C. Pierce <bcpierce at cis.upenn.edu> wrote:

>> Let's try the other way: ;)
>> Please give me the simplest open bug you have currently.
> 
> Here’s an amusing one that came up quite recently.  It’s not completely simple, but not extremely hard to fix either, I think.  
> 
> John Hughes and I decided (with Thomas Arts and Ulf Norell) to do a little QuickCheck-style property based random testing of Unison.  We used their Erlang version of QuickCheck, which has very nice support for generating state-machine-like test sequences.  And, lo and behold, in the first two hours of testing we found a significant (and subtle) bug!
> 
> What QuickCheck discovered was that, if Unison propagates a changed version of a file and, on the receiving replica, this file is immediately (within one second) overwritten by some other process with new contents of exactly the same size, then running Unison again will not propagate the newest change back to the first side.  
> 
> Best,
> 
>     - Benjamin
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20141026/c519095d/attachment-0001.html>