[Unison-hackers] fatal error in 2.17.1

[Seth Teller]

benjamin,

i believe that the following scenario describes
the fatal error.

both directory structures on A and B are identical
with one exception.  each top-level dir has a
file named "Thumbs.db".  on machine A, it is a
10Kb file.  on machine B, it is a 6Kb file (so
obviously they are different on A and B).

the files have different creation dates.

unison is run with "fastcheck = true" even for
its first invocation on both A and B.

if i remove the .db files, then start all over
with a blank central archive, everything works
fine.

seth

Seth Teller wrote:
> 
> nope, i am running in the recommended "star" topology,
> with a linux-unison on the CSAIL machine managing an
> archive under AFS, and two laptops, each sync'ing
> separately to the AFS archive (which i never use
> directly -- that is, i work only on the laptops).
> 
> the laptops are running windows XP.
> 
> seth
> 
> Benjamin Pierce wrote:
>> Aha -- this could be very useful.  This is a known bug, but we have  
>> been having trouble making a repeatable example of it.
>>
>> When you say "i sync A to a common, initially empty archive.  i then  
>> attempt to sync B to that same archive," do you mean that you are  
>> using *three* replicas, running unison between two pairs of them?   
>> (Unison uses the word "archive" for its own internal state that's  
>> stored between runs.)
>>
>> What OS are you running on?  Linux?
>>
>> Thanks,
>>
>>    - Benjamin
>>
>>
>> On Mar 7, 2007, at 10:05 AM, Seth Teller wrote:
>>
>>> hello,
>>>
>>> in case it's easier to just solve my original problem:
>>> the output of unison -debug all is excerpted below up
>>> to the point of
>>>
>>>    Fatal error: Internal error: New archives are not identical.
>>>
>>> does anyone know why this is occurring and how to fix it?
>>>
>>> the usage scenario is that i have two laptops A and B with
>>> slightly different directory trees.  i sync A to a common,
>>> initially empty archive.  i then attempt to sync B to that
>>> same archive.  the fatal error below issues, repeatably.
>>>
>>> thanks,
>>>
>>> seth
>>>
>>>
>>>
>>> [remote_emit] Remaining tokens: 00\000\000\015\000\000...' 35 bytes
>>> [server: remote_emit] Received the write permission
>>> [server: remote_emit] Received write token (1)
>>> [remote_emit] Restarting readeren
>>> [remote_emit] Waiting for next message
>>> [server: remote_emit] Waiting for next message
>>> [server: update] Saving archive in
>>> /afs/csail.mit.edu/u/s/seth/.unison/sce67c05688562d423b0f0ff094369de99
>>> [server: remote_emit] Sending result (id: 15)
>>> [server: remote_emit] send [prepareCommit-res]
>>> '\132\149\166\190\000\000\000\006\000\000...' 26 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] Remaining tokens: 0
>>> [server: remote_emit] Sending write token
>>> [server: remote_emit] Message received (id: 16) (tokens: 1)
>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...' 38
>>> bytes[remote_emit] Message received (id: 16) (toke
>>> ns: 1)
>>> [remote_emit] receive 'rspäòª+\000\000\000...' 24 bytes
>>> [server: remote_emit] receive 'unlockArch...' 76 bytes
>>> [server: remote_emit] Waiting for next message
>>> [server: remote_emit] Received the write permission
>>> [server: remote_emit] Received write token (1)<
>>>> [server: remote_emit] Waiting for next message!
>>> [server: remote_emit] Sending result (id: 16)
>>> [server: remote_emit] send [unlockArchive-res]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] Remaining tokens: 0ª+\000\000\000&\000 \000...' 58
>>> bytes
>>> [server: remote_emit] Sending write token0\013\000\000...' 33 bytes
>>> <>!<>![server: remote_emit] Message received (id: 17) (tokens: 1)
>>> [server: remote_emit] receive 'rsp\132\149\166\190\000\000\000...'  
>>> 36 bytes
>>> [server: remote_emit] receive 'dumpArchiv...' 74 bytes
>>> [server: remote_emit] Waiting for next message[remote_emit] Message
>>> received (id: 17) (tokens: 1)
>>> [server: remote_emit] Received the write permissionytes
>>> [server: remote_emit] Received write token (1)d
>>> Settings\seth\Desktop\unison\unison.dump'
>>> [server: remote_emit] Waiting for next message
>>> [server: update] Dumping archive into
>>> `/afs/csail.mit.edu/u/s/seth/unison.dump'
>>> [server: remote_emit] Sending result (id: 17)
>>> [server: remote_emit] send [dumpArchive-res]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes
>>> [server: remote_emit] send [rsp]
>>> '\132\149\166\190\000\000\000\001\000\000...' 21 bytes identical.
>>> [server: remote_emit] Remaining tokens: 0Unison again to bring them up
>>> to date.
>>> [server: remote_emit] Sending write token
>>> Fatal error: Internal error: New archives are not identical.
>>> C:\Documents and Settings\seth\Desktop>REM  > "C:\Documents and
>>> Settings\seth\Desktop\unison.txt" &
>>>
>>> C:\Documents and Settings\seth\Desktop>REM tail -f "C:\Documents and
>>> Settings\seth\Desktop\unison.txt"
>>>
>>> C:\Documents and Settings\seth\Desktop>REM wait until ctrl-C or window
>>> is closed
>>>
>>> C:\Documents and Settings\seth\Desktop>pause
>>> Press any key to continue . . . [server: remote] Connection closed by
>>> the client
>>> _______________________________________________
>>> Unison-hackers mailing list
>>> Unison-hackers at lists.seas.upenn.edu
>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>>>
>>
>> _______________________________________________
>> Unison-hackers mailing list
>> Unison-hackers at lists.seas.upenn.edu
>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers