Unison-2.9.1 bug (I think)

Discussion:

Karl Moerder

2002-08-23 00:10:19 UTC

Hi All...

I believe that I found the following bug...or I am confused...so here
goes...

Consider three machines (all win2k in this case) and consider a file that
exists on all three roots. Modify the file on machine A in a way that
fastcheck will not detect. Do a safe synch with A and B. Do a safe sync with
B and C. Now do a fast sync with C and A (from C). The update fails and
claims that the file was modified during transfer.

Any thoughts?

Thanks,

...Karl

Karl Moerder

2002-08-23 14:57:25 UTC

Permalink

Hi All...

If I do a touch on the offending file (on the destination machine) and then
restart unison from the gui the file goes away from the list of proposed
updates.

Thanks,

...Karl

-----Original Message-----
From: Karl Moerder [mailto:***@cox.net]
Sent: Thursday, August 22, 2002 5:10 PM
To: Unison Development Team (E-mail)
Cc: Benjamin Pierce (E-mail)
Subject: Unison-2.9.1 bug (I think)

Hi All...

I believe that I found the following bug...or I am confused...so here
goes...

Consider three machines (all win2k in this case) and consider a file that
exists on all three roots. Modify the file on machine A in a way that
fastcheck will not detect. Do a safe synch with A and B. Do a safe sync with
B and C. Now do a fast sync with C and A (from C). The update fails and
claims that the file was modified during transfer.

Any thoughts?

Thanks,

...Karl

Benjamin C. Pierce

2002-08-24 11:47:21 UTC

Permalink

Post by Karl Moerder
I believe that I found the following bug...or I am confused...so here
goes...
Consider three machines (all win2k in this case) and consider a file that
exists on all three roots. Modify the file on machine A in a way that
fastcheck will not detect. Do a safe synch with A and B. Do a safe sync with
B and C. Now do a fast sync with C and A (from C). The update fails and
claims that the file was modified during transfer.

This looks to me like correct behavior. You modified a file in a way
that Unison did not detect. Later, it tried to propagate a change from
somewhere else on top of that file, and at that point it realized that
the file's contents were not what it thought and refused to do the
propagation. Seems right. (OK, the error message could be clearer.)

B

P.S. The '***@cis.upenn.edu' and 'unison-***@cis.upenn.edu'
addresses are now aliases for 'unison-***@yahoogroups.com'.

Karl Moerder

2002-11-08 14:41:21 UTC

Permalink

Hi All...

What if when his happens, unison still updates its database to the new file
fingerprint? Then the next time I run it, it will heal itself. Or...perhaps
it could just invalidate the signature (like set it to zero) when this
condition is detected and then again, it would be healed next time unison is
run.

Another possibility is to use the path dependent preferences that have been
discussed to avoid fastcheck on *.xls files in the windows environment.
These cause the problem because excel modifies the file without changing the
dates or length. (It marks the file with the user that has parts of the file
to allow sharing of the file between multiple users.) Any thoughts on the
status of path dependent preferences?

Another possibility would be a less general mechanism to disallow fastcheck
on certain file types. Like a pattern for "always check the file" when it
matches "this pattern". And then I would just set the pattern to a glob or
regex for "*.xls".

Are any of these feasible (in the near future)? Are there any bad side
effects?

Thanks,

...Karl

-----Original Message-----
From: Benjamin C. Pierce [mailto:***@saul.cis.upenn.edu]
Sent: Saturday, August 24, 2002 4:47 AM
To: Karl Moerder
Cc: unison-***@yahoogroups.com
Subject: Re: Unison-2.9.1 bug (I think)

Benjamin C. Pierce

2002-11-09 02:35:31 UTC

Permalink

Post by Karl Moerder
What if when his happens, unison still updates its database to the new file
fingerprint? Then the next time I run it, it will heal itself. Or...perhaps
it could just invalidate the signature (like set it to zero) when this
condition is detected and then again, it would be healed next time unison is
run.

I think all these would be violations of Unison's specification -- I'd
prefer to find another way...

Post by Karl Moerder
Another possibility is to use the path dependent preferences that have been
discussed to avoid fastcheck on *.xls files in the windows environment.
These cause the problem because excel modifies the file without changing the
dates or length. (It marks the file with the user that has parts of the file
to allow sharing of the file between multiple users.) Any thoughts on the
status of path dependent preferences?
Another possibility would be a less general mechanism to disallow fastcheck
on certain file types. Like a pattern for "always check the file" when it
matches "this pattern". And then I would just set the pattern to a glob or
regex for "*.xls".
Are any of these feasible (in the near future)? Are there any bad side
effects?

I like the last option -- add a "-nofastcheck" option that takes a path
argument (with the same regexp features as other path specs like
ignore). This would be a fairly easy hack, I think. (Any colunteers?)

B

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/JjlUgA/vN2EAA/kG8FAA/26EolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
unison-hackers-***@yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/