headers
Simson Garfinkel | 1 Oct 2008 03:57
Picon
Favicon
Gravatar

Destination updated during synchronization

I have scanned through the archives and through other people's random  
postings found via Google, but can't find the answer to this.

I have several machines that I keep synched using Unison. The "master"  
repository that every machine syncs with is a Linux system running a  
case-sensitive file system. The slaves are Macs and Linux boxes. Some  
are case-sensitive, some are not.

With great regularity one or more of the .doc file files in the sync  
directories start reporting with this error:

Failed [admin/Garfinkel_Annual_Report_CY2008.doc]: Destination updated  
during synchronization

No change is made prior to this happening. It just happens. And once  
it starts happening, it continues to happen until I manually change  
the name on one of the systems. No option seems to be able to "reset"  
the flag.

I see in the archives that this has happened to other people. But  
nobody has ever been able to figure out a reason for it.

Any suggestions for debugging this? I really think that it's a bug in  
the code base.

And yes, it only seems to happen with .doc files.

Thanks!

------------------------------------
(Continue reading)

Permalink | Reply | 6 comments |
headers
Benjamin Pierce | 1 Oct 2008 04:16
Favicon

Re: Destination updated during synchronization

Have you tried running with -fastcheck=false?  The usual reason for  
this happening is that some program changes the file but doesn't  
change the modtime or length, so Unison's initial scan shows it as  
unchanged but then it discovers later that the whole-file fingerprint  
is not what it expects...

    - Benjamin

On Sep 30, 2008, at 9:57 PM, Simson Garfinkel wrote:

> I have scanned through the archives and through other people's random
> postings found via Google, but can't find the answer to this.
>
> I have several machines that I keep synched using Unison. The "master"
> repository that every machine syncs with is a Linux system running a
> case-sensitive file system. The slaves are Macs and Linux boxes. Some
> are case-sensitive, some are not.
>
> With great regularity one or more of the .doc file files in the sync
> directories start reporting with this error:
>
> Failed [admin/Garfinkel_Annual_Report_CY2008.doc]: Destination updated
> during synchronization
>
> No change is made prior to this happening. It just happens. And once
> it starts happening, it continues to happen until I manually change
> the name on one of the systems. No option seems to be able to "reset"
> the flag.
>
> I see in the archives that this has happened to other people. But
(Continue reading)

Permalink | Reply | 5 comments |
headers
Simson Garfinkel | 1 Oct 2008 06:17
Picon
Favicon
Gravatar

Re: Destination updated during synchronization

Hi, Benjamin.

You know, I had previously tried -fastcheck=false and it didn't help,  
but I just tried it and it did.

This is so weird!

Why do you think that this is happening so often?

Is there any way we could make unison fall back into fastcheck=false  
for the files that generate these errors?

-Simson

Also, I know for a fact that no problem is changing the file.

On Sep 30, 2008, at 7:16 PM, Benjamin Pierce wrote:

> Have you tried running with -fastcheck=false?  The usual reason for  
> this happening is that some program changes the file but doesn't  
> change the modtime or length, so Unison's initial scan shows it as  
> unchanged but then it discovers later that the whole-file  
> fingerprint is not what it expects...
>
>   - Benjamin

------------------------------------

Yahoo! Groups Links
(Continue reading)

Permalink | Reply | 4 comments |
headers
mxsteini | 1 Oct 2008 13:40
Picon
Picon

rollback journal

Hi there,
I'm new at unison and I found it great.
I syncronize my laptop and my Desktop and it is working great.

Now I need a good software for backup an rollback.
Is there a plan in integrate something like that in unison?

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:unison-users-digest <at> yahoogroups.com 
    mailto:unison-users-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Pierce | 1 Oct 2008 14:52
Favicon

Re: Destination updated during synchronization

> You know, I had previously tried -fastcheck=false and it didn't help,
> but I just tried it and it did.
>
> This is so weird!
>
> Why do you think that this is happening so often?
>
> Is there any way we could make unison fall back into fastcheck=false
> for the files that generate these errors?

Well, the textual user interface does have the capability of retrying  
the sync on paths with transfers that fail.  One could turn off  
fastcheck completely when this happens, I suppose.

> Also, I know for a fact that no problem is changing the file.

Do you know for a fact that the MD5 hash of the file has not  
changed?  If so, then there is a bug in Unison.  If not, then  
somebody is changing it.

Best,

     - Benjamin

>
> On Sep 30, 2008, at 7:16 PM, Benjamin Pierce wrote:
>
>> Have you tried running with -fastcheck=false?  The usual reason for
>> this happening is that some program changes the file but doesn't
>> change the modtime or length, so Unison's initial scan shows it as
(Continue reading)

Permalink | Reply | 3 comments |
headers
melk600 | 1 Oct 2008 17:16

Re: Destination updated during synchronization

I have had this problem in the past although it was with .xls files
not .doc files.  My first question would be what version of unison are
you using?  I haven't had the problem since around 2.24 and up.

Mike

--- In unison-users <at> yahoogroups.com, Benjamin Pierce <bcpierce <at> ...> wrote:
>
> > You know, I had previously tried -fastcheck=false and it didn't help,
> > but I just tried it and it did.
> >
> > This is so weird!
> >
> > Why do you think that this is happening so often?
> >
> > Is there any way we could make unison fall back into fastcheck=false
> > for the files that generate these errors?
> 
> Well, the textual user interface does have the capability of retrying  
> the sync on paths with transfers that fail.  One could turn off  
> fastcheck completely when this happens, I suppose.
> 
> > Also, I know for a fact that no problem is changing the file.
> 
> Do you know for a fact that the MD5 hash of the file has not  
> changed?  If so, then there is a bug in Unison.  If not, then  
> somebody is changing it.
> 
> Best,
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Simson Garfinkel | 1 Oct 2008 19:00
Picon
Favicon
Gravatar

Re: Re: Destination updated during synchronization

I'm using 2.27.57

Thanks!

On Oct 1, 2008, at 8:16 AM, melk600 wrote:

> I have had this problem in the past although it was with .xls files
> not .doc files.  My first question would be what version of unison are
> you using?  I haven't had the problem since around 2.24 and up.
>
> Mike
>
>
> --- In unison-users <at> yahoogroups.com, Benjamin Pierce <bcpierce <at> ...>  
> wrote:
>>
>>> You know, I had previously tried -fastcheck=false and it didn't  
>>> help,
>>> but I just tried it and it did.
>>>
>>> This is so weird!
>>>
>>> Why do you think that this is happening so often?
>>>
>>> Is there any way we could make unison fall back into fastcheck=false
>>> for the files that generate these errors?
>>
>> Well, the textual user interface does have the capability of retrying
>> the sync on paths with transfers that fail.  One could turn off
>> fastcheck completely when this happens, I suppose.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simson Garfinkel | 1 Oct 2008 19:22
Picon
Favicon
Gravatar

Re: Destination updated during synchronization

>>
>
> Do you know for a fact that the MD5 hash of the file has not  
> changed?  If so, then there is a bug in Unison.  If not, then  
> somebody is changing it.

I don't know this for a fact. I will try to generate some facts for  
you. I am running time machine, so that shouldn't be too hard.

>
>
> Best,
>
>    - Benjamin
>
>
>>
>> On Sep 30, 2008, at 7:16 PM, Benjamin Pierce wrote:
>>
>>> Have you tried running with -fastcheck=false?  The usual reason for
>>> this happening is that some program changes the file but doesn't
>>> change the modtime or length, so Unison's initial scan shows it as
>>> unchanged but then it discovers later that the whole-file
>>> fingerprint is not what it expects...
>>>
>>>  - Benjamin
>>
>>
>> ------------------------------------
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
modharsee | 3 Oct 2008 00:17
Picon
Favicon

Unison hanging, eating memory on Windows

I'm using Unison 2.9.1 on Win XP SP3 to mirror a directory and subdirs 
over the network to a Windows 2003 Server box. 

During the fastcheck phase, everything is fine. I click Go and it 
starts syncing and that's when I notice the following issues:

1) memory usage keeps increasing throughout the sync process; for a 5 
GB directory, it reaches about 800 Mb. For a 20 GB directory, the 
process crashes, presumably because of reaching the allowable process 
memory limit (I have 2 GB RAM on the box).

2) toward the end, when every entry is at 99 or 100%, it just hangs 
there with CPU usage at about 5%. In most cases, memory usage remains 
more or less constant during the hang. Finally, after about 20 minutes, 
the GUI recovers and reports that the sync completed successfully.

Using the command-line interface doesn't change anything. If anyone 
else has experienced these issues, it would be great to know. 

Thanks,
Moyez

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> Your email settings:
(Continue reading)

Permalink | Reply | 1 comment |
headers
modharsee | 3 Oct 2008 03:21
Picon
Favicon

Re: Unison hanging, eating memory on Windows

I finally realized I was using a much older version 2.9.1 than the
current stable release. With 2.27.57, the apparent memory leak is no
longer an issue, which is wonderful.

However, there is still a very long "pause" after all files are
synced and the status shows 100%. After about 30 minutes, things
finally come to a close and the GUI reports "Synchronization
Complete".

During the "pause":

- CPU is at 5-10%
- memory usage does not change at all
- network bandwidth is at about 50 Mbps (50% usage in my case)
- the GUI status bar says "propogating changes" followed by the name
of the top-most directory
- the last debug output on the console is:

  [update] replaceArchiveLocal Y:/backup/Projects {parentFolder}

  (where {parentFolder} is the name of top-level directory being
sync'd)

Since there is network traffic, it could be that some activity of
reasonable importance is actually happening but progress on this
activity is just not reported. If anyone knows why this occurs or has
experienced something similar, would really appreciate your thoughts.

Thanks!
Moyez
(Continue reading)

Permalink | Reply | 0 comments |

Gmane