[prev in list] [next in list] [prev in thread] [next in thread]
List: unison-users
Subject: RE: [unison-users] Unison issue Fatal error: inconsistent state
From: "Zdenek () gmail" <zdenek ! sekera () gmail ! com>
Date: 2007-10-04 13:12:10
Message-ID: 4704e6ab.26a75e0a.1a14.05f4 () mx ! google ! com
[Download RAW message or body]
Hi, Benjamin,
happy to hear from you, I haven't gotten much further
since I have sent my original email, though I tried quite
hard. I'll try more using your suggestions and will
come back to you. It will take me a few days due to
some other urgent work. Thanks again!
---Zdenek
> -----Original Message-----
> From: Benjamin Pierce [mailto:bcpierce@cis.upenn.edu]
> Sent: 04 October 2007 14:48
> To: Zdenek@gmail
> Cc: 'Derek Rayside'; unison-users@yahoogroups.com
> Subject: Re: [unison-users] Unison issue Fatal error: inconsistent
> state
>
> Hi,
>
> I've been looking at the query you sent a few weeks ago. I don't
> have a very clear understanding of what might be going on (I agree
> with Derek that it may have something to do with AFS), but I can
> offer some thoughts:
>
> One of the first things Unison does during its startup phase is to
> "canonize" the names of the roots. This involves doing something
> with the name of the host (which seems to be OK in your case) and
> with the path to the root on each host (which is where problems seem
> to be arising). The function that does the latter operation is
> canonizeFspath, in the Fspath module. Basically, it is attempting to
> "cd" to the given root directory, then do a "getcwd" to find out what
> it is really called, according to the host on which it lives.
>
> You can get a slightly clearer view of how the roots are being
> canonized just by giving the '-debug all' flag on the command line.
> But if that doesn't clarify things enough, you'll probably want to
> insert some additional tracing statements, to try to track down where
> a wrong value seems to be arising in the control flow. Look
> elsewhere in fspath.ml for statements like
>
> debug
> (fun() ->
> Util.msg "Os.findWorkingDir(%s,%s) = (%s,%s)\n"
> (toString fspath)
> (Path.toString path)
> (myDirname realpath)
> p);
>
> for a template of how to write things out.
>
> Now, to answer one question from your mail...
>
> >>> Just out of curiosity: my experience shows that ar* files is never
> >> much
> >>> bigger than 1Mb, it will be split if it should come bigger. Why?
>
> ar files are never "split". One archive is created for each root, on
> the host where that root lives.
>
> Regards,
>
> - Benjamin
>
>
>
> On Sep 7, 2007, at 2:42 AM, Zdenek@gmail wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Derek Rayside [mailto:drayside@csail.mit.edu] On Behalf Of
> >> Derek
> >> Rayside
> > [...]
> >>
> >> I just skimmed over your email, and noticed that you're using AFS
> >> from
> >> multiple computers. You'll want to use the UNISONLOCALHOSTNAME
> >> variable
> >> on any machines that mount AFS. That may not be related to the
> issue
> >> you're reporting here, but if you don't use it you'll get other
> >> issues.
> >
> > Yes, I *do* use it. I didn't mention it because I believe
> > it is indeed not related to my problem. And yes, if one doesn't
> > use UNISONLOCALHOSTNAME in these circumstances, one *does*
> > get other problems, I tried :-).
> >
> > ---Zdenek
> >
> >>
> >> On Tue, 4 Sep 2007, Zdenek Sekera wrote:
> >>
> >>> Sorry for the length, I tried to describe in details
> >>> all steps permitting to reproduce reliably the error.
> >>>
> >>> All '.unison' directories are clean, no ar* anywhere.
> >>> -----------------------------------------------------
> >>> 1. on the machine 'pcitdi10'
> >>>
> >>>> unison zs_common $HOME $AFS/w0/common
> >>> where:
> >>> -> $HOME=/home/zs
> >>> -> $AFS =/afs/cern.ch/user/s/sekera
> >>> This command issues the following comment:
> >>> Connected [//pcitdi10.cern.ch//afs/cern.ch/user/s/sekera/w0/
> >>> common -
> >>>
> >>> //pcitdi10.cern.ch//home/zs]
> >>> This seems correct, the AFS is indeed mounted on 'pcitdi10' and
> >>> this
> >> PATH
> >>> just says this is a synchronization of two "folders" on the same
> >> machine.
> >>> I get the usual warning 'no archives were found for these
> roots...'
> >> because
> >>> it is the first time.
> >>> The run correctly found identical files I've put in both roots
> >>> (as a
> >> test)
> >>> and finished properly.
> >>> Two ar* files were produced:
> >>>
> >>>> cd .unison -> on pcitdi10
> >>>> ls -l ar*
> >>> -rw------- 1 zs zs 1030510 Sep 4 15:01
> >> ar34d7b618ce27e1cc31527fcce3940f7d
> >>> -rw------- 1 zs zs 1030542 Sep 4 15:01
> >> ardbd9badeb161b7255ada8929187ec337
> >>>
> >>> Just out of curiosity: my experience shows that ar* files is never
> >> much
> >>> bigger than 1Mb, it will be split if it should come bigger. Why?
> >>>
> >>> 2. Now: the AFS file system is also accessible from another machine
> >>> 'lxplus' where it is mounted.The machine can be accessed via
> >>> 'ssh'.
> >>> This machine is the heart of my *star*
> >>> arrangement, other machines, that do not have direct access to
> AFS
> >>> will be synchronized using 'lxplus' machine accessed by 'ssh'.
> >>>
> >>> So I expected that the following execution will proceed without
> >>> anything particular (because it should now synchronize identical
> >>> roots), however, it is not *quite* so:
> >>>
> >>>> unison zs_common $HOME ssh://sekera@lxplus.cern.ch/$AFS/w0/common
> >>>
> >>> Note roots are identical to the previous test, only the access to
> >>> ROOT2 is via 'ssh'.
> >>>
> >>> a. I get the same "no archive files were found for these
> roots..."
> >>> message. This may (probably is) correct since 'unison' cannot
> >> know
> >>> that those two roots are in fact identical to the previous
> >>> test.
> >>> b. However, and it bothers me very much, the following message is
> >>> displayed by 'unison'
> >>>
> >>> Connected [//lxplus.cern.ch//afs/cern.ch/user/s/sekera/w0/common -
> >
> >>> //lxplus.cern.ch//home/zs]
> >>>
> >>> While the first part is correct (the AFS root is accessed from
> >> lxplus
> >>> using ssh, the second part seems to me wrong:
> >>> I would have expected it to be identical to the first test above,
> >>> that is: //pcitdi10.cern.ch//home/zs
> >>> Indeed, when executing unison for this test, the '/home/zs' ROOT
> is
> >>> on pcitdi10 and *not* on 'lxplus'. There is *no* /home/zs on
> >>> lxplus.
> >>>
> >>> Nevertheless, unison will find that both roots are identical and
> >>> do nothing, except generating the appropriate ar* file in my
> >>> HOME directory on lxplus (which happens to be part of the AFS
> >>> namely: /afs/cern.ch/user/s/sekera
> >>>
> >>> New ar* file will also be created on the originating 'pcitdi10':
> >>>
> >>>> ls -lrt
> >>> -rw------- 1 zs zs 1030542 Sep 4 15:01
> >> ardbd9badeb161b7255ada8929187ec337
> >>> -rw------- 1 zs zs 1030510 Sep 4 15:01
> >> ar34d7b618ce27e1cc31527fcce3940f7d
> >>> -rw------- 1 zs zs 1030578 Sep 4 15:22
> >> arcc21948e8f9896b0cc8a8798135ad5f3
> >>>
> >>> Remember first two are from the previous run.
> >>> The interesting thing (for me anyway) is that only one ar* was
> >> needed
> >>> rather than two as before.
> >>>
> >>> The analysis of those files (which I think is relevent to the
> >> problem
> >>> below)
> >>> is this:
> >>>
> >>>> strings ardbd9badeb161b7255ada8929187ec337 | head -3
> >>> Unison archive format 22
> >>> Archive for root
> >> //pcitdi10.cern.ch//afs/cern.ch/user/s/sekera/w0/common
> >>> synchronizing roots
> >> //pcitdi10.cern.ch//afs/cern.ch/user/s/sekera/w0/common,
> >>> //pcitdi10.cern.ch//home/zs
> >>> Written at 2007-09-04 at 15:01:30
> >>>
> >>> strings ar34d7b618ce27e1cc31527fcce3940f7d | head -3
> >>> Unison archive format 22
> >>> Archive for root //pcitdi10.cern.ch//home/zs synchronizing roots
> >>> //pcitdi10.cern.ch//afs/cern.ch/user/s/sekera/w0/common,
> >>> //pcitdi10.cern.ch//home/zs
> >>> Written at 2007-09-04 at 15:01:30
> >>>
> >>> strings arcc21948e8f9896b0cc8a8798135ad5f3|head -3
> >>> Unison archive format 22
> >>> Archive for root //lxplus.cern.ch//home/zs synchronizing roots
> >>> //lxplus.cern.ch//afs/cern.ch/user/s/sekera/w0/common,
> >>> //lxplus.cern.ch//home/zs
> >>> Written at 2007-09-04 at 15:22:46
> >>>
> >>> So these ar* files *remember* how the synchronization was made.
> >>> Note
> >> that
> >>> the ROOT /home/zs has the wrong machine name associated with it,
> >>> it should be //pcitdi10.cern.ch/ and *not* //lxplus.cern.ch/, this
> >>> *must* be an error in unison IMHO.
> >>>
> >>> 3. This step will generat the error, consistently repeatable:
> >>>
> >>> I go now to another machine 'pcitpb12', which has an 'ssh' access
> >>> to 'lxplus', so I should be able to synchronize the AFS ROOT
> >>> from lxplus with my ROOT on 'pcitpb12'.
> >>> More precisely, I execute the following on 'pcitpb12':
> >>>
> >>>> unison zs_common $HOME ssh://sekera@lxplus.cern.ch/$AFS/w0/common
> >>>
> >>> This is *exactly* the same command as in the 2. case above, the
> >>> difference being that this time my $HOME ROOT in on 'pcitpb12'
> >>> (where the unison command is executed). It so happens that
> >>> $HOME=/home/zs on both 'pcitpb12' and 'pcitdi10' (comparing still
> >>> case 2 and 3) but it shouldn't be an issue..
> >>>
> >>> The command displays this:
> >>>
> >>> Connected [//lxplus.cern.ch//afs/cern.ch/user/s/sekera/w0/common -
> >
> >>> //lxplus.cern.ch//home/zs]
> >>>
> >>> Which is identical to the case above except this time the HOME
> ROOT
> >>> should read //pcitpb12.cern.ch/ and *not* //lxplus.cern.ch/.
> Again,
> >>> lxplus has no '/home/zs' directory on it.
> >>>
> >>> And now the final error, unison will display the following
> message:
> >>>
> >>> ----------------------------------------------------------------
> >>> Fatal error:
> >>> Warning: inconsistent state.
> >>> The archive file is missing on some hosts.
> >>> For safety, the remaining copies should be deleted.
> >>> Archive arcc21948e8f9896b0cc8a8798135ad5f3 on host lxplus.cern.ch
> >> is
> >>> MISSING.
> >>> Archive ar7cf2d2aef5c0de5c94288b65c0694ac0 on host lxplus.cern.ch
> >> should
> >>> be
> >>> DELETED.
> >>> Please delete archive files as appropriate and try again.
> >>> ----------------------------------------------------------------
> >>> A few comments to this message:
> >>>
> >>> a. Indeed, there is no arcc* file on lxplus.cern.ch.
> >>> The only ar* file that's there is:
> >> ar7cf2d2aef5c0de5c94288b65c0694ac0
> >>> it says:
> >>> strings ar7cf2d2aef5c0de5c94288b65c0694ac0 |head -3
> >>> Unison archive format 22
> >>> Archive for root
> >> //lxplus.cern.ch//afs/cern.ch/user/s/sekera/w0/common
> >>> synchronizing roots
> >>> //lxplus.cern.ch//afs/cern.ch/user/s/sekera/w0/common,
> >>> //lxplus.cern.ch//home/zs
> >>> Written at 2007-09-04 at 15:22:46
> >>>
> >>> Again the HOME root is wrong, so it cannot be determined how
> the
> >> file
> >>> was generated (which ROOTs were synchronized), though we know
> it
> >> is
> >>> the result on run 2 above.
> >>>
> >>> b. The ar7c* is indeed on lxplus as noted above, but it should be
> >> perfectly
> >>> legitimate (perhaps it would be if the HOME ROOT was correct).
> >>>
> >>> c. If I indeed proceed as requested in the error message (delete
> >>> the
> >>> file and restart unison, it will make the "standard" initial
> run
> >>> ('no archives were found for these roots...') and the unison
> >>> will
> >> run.
> >>>
> >>> However, next time, when I want to synchronize from another
> >> machine
> >>> and ROOT is that AFS ROOT, I will get the same error, so I have
> >> to
> >>> always delete all ar* files to be able to run, so there is in
> >>> fact no synchronization per say.
> >>>
> >>> For completeness, in my 'zs_common.prf' file I have a statement to
> >> igonre
> >>> .unison/ar* files (as suggested in unison user manual), don't
> >>> know if
> >>> it is relevent to this case.
> >>>
> >>> Has anybody run into such problems? Is it me who is doing something
> >>> wrong or is this a genuaine unison bug (as I tend to believe)?
> >>>
> >>> For developers: I am ready to run any test you may wish, the
> problem
> >>> is perfectly reproducible with steps above, it only takes some
> time.
> >>>
> >>> Best regards,
> >>>
> >>> ---Zdenek
> >>>
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" \
"http://www.w3.org/TR/html4/strict.dtd"> <html>
<head>
</head>
<body style="background-color: #ffffff;">
<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id="ygrp-mlmsg" style="width:655px; position:relative;">
<div id="ygrp-msg" style="width: 490px; padding: 0 15px 0 0; float:left; \
z-index:1;"> <!--~-|**|PrettyHtmlEndT|**|-~-->
<div id="ygrp-text">
<p>Hi, Benjamin,<br>
<br>
happy to hear from you, I haven't gotten much further<br>
since I have sent my original email, though I tried quite<br>
hard. I'll try more using your suggestions and will<br>
come back to you. It will take me a few days due to<br>
some other urgent work. Thanks again!<br>
<br>
---Zdenek<br>
<br>
> -----Original Message-----<br>
> From: Benjamin Pierce [mailto:<a \
href="mailto:bcpierce%40cis.upenn.edu">bcpierce@cis.<wbr>upenn.edu</a>]<br> > \
Sent: 04 October 2007 14:48<br> > To: Zdenek@gmail<br>
> Cc: 'Derek Rayside'; <a \
href="mailto:unison-users%40yahoogroups.com">unison-users@<wbr>yahoogroups.<wbr>com</a><br>
> Subject: Re: [unison-users] Unison issue Fatal error: inconsistent<br>
> state<br>
> <br>
> Hi,<br>
> <br>
> I've been looking at the query you sent a few weeks ago. I don't<br>
> have a very clear understanding of what might be going on (I agree<br>
> with Derek that it may have something to do with AFS), but I can<br>
> offer some thoughts:<br>
> <br>
> One of the first things Unison does during its startup phase is to<br>
> "canonize" the names of the roots. This involves doing something<br>
> with the name of the host (which seems to be OK in your case) and<br>
> with the path to the root on each host (which is where problems seem<br>
> to be arising). The function that does the latter operation is<br>
> canonizeFspath, in the Fspath module. Basically, it is attempting to<br>
> "cd" to the given root directory, then do a "getcwd" to find \
out what<br> > it is really called, according to the host on which it lives.<br>
> <br>
> You can get a slightly clearer view of how the roots are being<br>
> canonized just by giving the '-debug all' flag on the command line.<br>
> But if that doesn't clarify things enough, you'll probably want to<br>
> insert some additional tracing statements, to try to track down where<br>
> a wrong value seems to be arising in the control flow. Look<br>
> elsewhere in fspath.ml for statements like<br>
> <br>
> debug<br>
> (fun() -><br>
> Util.msg "Os.findWorkingDir(<wbr>%s,%s) = (%s,%s)\n"<br>
> (toString fspath)<br>
> (Path.toString path)<br>
> (myDirname realpath)<br>
> p);<br>
> <br>
> for a template of how to write things out.<br>
> <br>
> Now, to answer one question from your mail...<br>
> <br>
> >>> Just out of curiosity: my experience shows that ar* files is \
never<br> > >> much<br>
> >>> bigger than 1Mb, it will be split if it should come bigger. \
Why?<br> > <br>
> ar files are never "split". One archive is created for each root, \
on<br> > the host where that root lives.<br>
> <br>
> Regards,<br>
> <br>
> - Benjamin<br>
> <br>
> <br>
> <br>
> On Sep 7, 2007, at 2:42 AM, Zdenek@gmail wrote:<br>
> <br>
> ><br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Derek Rayside [mailto:<a \
href="mailto:drayside%40csail.mit.edu">drayside@csail.<wbr>mit.edu</a>] On Behalf \
Of<br> > >> Derek<br>
> >> Rayside<br>
> > [...]<br>
> >><br>
> >> I just skimmed over your email, and noticed that you're using AFS<br>
> >> from<br>
> >> multiple computers. You'll want to use the UNISONLOCALHOSTNAME<br>
> >> variable<br>
> >> on any machines that mount AFS. That may not be related to the<br>
> issue<br>
> >> you're reporting here, but if you don't use it you'll get other<br>
> >> issues.<br>
> ><br>
> > Yes, I *do* use it. I didn't mention it because I believe<br>
> > it is indeed not related to my problem. And yes, if one doesn't<br>
> > use UNISONLOCALHOSTNAME in these circumstances, one *does*<br>
> > get other problems, I tried :-).<br>
> ><br>
> > ---Zdenek<br>
> ><br>
> >><br>
> >> On Tue, 4 Sep 2007, Zdenek Sekera wrote:<br>
> >><br>
> >>> Sorry for the length, I tried to describe in details<br>
> >>> all steps permitting to reproduce reliably the error.<br>
> >>><br>
> >>> All '.unison' directories are clean, no ar* anywhere.<br>
> >>> ------------<wbr>---------<wbr>---------<wbr>---------<wbr>---------<wbr>-----<br>
> >>> 1. on the machine 'pcitdi10'<br>
> >>><br>
> >>>> unison zs_common $HOME $AFS/w0/common<br>
> >>> where:<br>
> >>> -> $HOME=/home/<wbr>zs<br>
> >>> -> $AFS =/afs/cern.ch/<wbr>user/s/sekera<br>
> >>> This command issues the following comment:<br>
> >>> Connected \
[//pcitdi10.<wbr>cern.ch//<wbr>afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<br> > \
>>> common -<br> > >>><br>
> >>> //pcitdi10.cern.<wbr>ch//home/<wbr>zs]<br>
> >>> This seems correct, the AFS is indeed mounted on 'pcitdi10' \
and<br> > >>> this<br>
> >> PATH<br>
> >>> just says this is a synchronization of two "folders" on \
the same<br> > >> machine.<br>
> >>> I get the usual warning 'no archives were found for these<br>
> roots...'<br>
> >> because<br>
> >>> it is the first time.<br>
> >>> The run correctly found identical files I've put in both roots<br>
> >>> (as a<br>
> >> test)<br>
> >>> and finished properly.<br>
> >>> Two ar* files were produced:<br>
> >>><br>
> >>>> cd .unison -> on pcitdi10<br>
> >>>> ls -l ar*<br>
> >>> -rw------- 1 zs zs 1030510 Sep 4 15:01<br>
> >> ar34d7b618ce27e1cc3<wbr>1527fcce3940f7d<br>
> >>> -rw------- 1 zs zs 1030542 Sep 4 15:01<br>
> >> ardbd9badeb161b7255<wbr>ada8929187ec337<br>
> >>><br>
> >>> Just out of curiosity: my experience shows that ar* files is \
never<br> > >> much<br>
> >>> bigger than 1Mb, it will be split if it should come bigger. \
Why?<br> > >>><br>
> >>> 2. Now: the AFS file system is also accessible from another \
machine<br> > >>> 'lxplus' where it is mounted.The machine can be \
accessed via<br> > >>> 'ssh'.<br>
> >>> This machine is the heart of my *star*<br>
> >>> arrangement, other machines, that do not have direct access \
to<br> > AFS<br>
> >>> will be synchronized using 'lxplus' machine accessed by \
'ssh'.<br> > >>><br>
> >>> So I expected that the following execution will proceed \
without<br> > >>> anything particular (because it should now \
synchronize identical<br> > >>> roots), however, it is not *quite* \
so:<br> > >>><br>
> >>>> unison zs_common $HOME <a \
href="ssh://sekera@lxplus.cern.ch/$AFS/w0/common">ssh://sekera@<wbr>lxplus.cern.<wbr>ch/$AFS/w0/<wbr>common</a><br>
> >>><br>
> >>> Note roots are identical to the previous test, only the access \
to<br> > >>> ROOT2 is via 'ssh'.<br>
> >>><br>
> >>> a. I get the same "no archive files were found for these<br>
> roots..."<br>
> >>> message. This may (probably is) correct since 'unison' \
cannot<br> > >> know<br>
> >>> that those two roots are in fact identical to the previous<br>
> >>> test.<br>
> >>> b. However, and it bothers me very much, the following message \
is<br> > >>> displayed by 'unison'<br>
> >>><br>
> >>> Connected \
[//lxplus.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common -<br> > \
><br> > >>> //lxplus.cern.<wbr>ch//home/<wbr>zs]<br>
> >>><br>
> >>> While the first part is correct (the AFS root is accessed from<br>
> >> lxplus<br>
> >>> using ssh, the second part seems to me wrong:<br>
> >>> I would have expected it to be identical to the first test \
above,<br> > >>> that is: //pcitdi10.cern.<wbr>ch//home/<wbr>zs<br>
> >>> Indeed, when executing unison for this test, the '/home/zs' \
ROOT<br> > is<br>
> >>> on pcitdi10 and *not* on 'lxplus'. There is *no* /home/zs on<br>
> >>> lxplus.<br>
> >>><br>
> >>> Nevertheless, unison will find that both roots are identical \
and<br> > >>> do nothing, except generating the appropriate ar* file in \
my<br> > >>> HOME directory on lxplus (which happens to be part of the \
AFS<br> > >>> namely: /afs/cern.ch/<wbr>user/s/sekera<br>
> >>><br>
> >>> New ar* file will also be created on the originating \
'pcitdi10':<br> > >>><br>
> >>>> ls -lrt<br>
> >>> -rw------- 1 zs zs 1030542 Sep 4 15:01<br>
> >> ardbd9badeb161b7255<wbr>ada8929187ec337<br>
> >>> -rw------- 1 zs zs 1030510 Sep 4 15:01<br>
> >> ar34d7b618ce27e1cc3<wbr>1527fcce3940f7d<br>
> >>> -rw------- 1 zs zs 1030578 Sep 4 15:22<br>
> >> arcc21948e8f9896b0c<wbr>c8a8798135ad5f3<br>
> >>><br>
> >>> Remember first two are from the previous run.<br>
> >>> The interesting thing (for me anyway) is that only one ar* was<br>
> >> needed<br>
> >>> rather than two as before.<br>
> >>><br>
> >>> The analysis of those files (which I think is relevent to the<br>
> >> problem<br>
> >>> below)<br>
> >>> is this:<br>
> >>><br>
> >>>> strings ardbd9badeb161b7255<wbr>ada8929187ec337 | head -3<br>
> >>> Unison archive format 22<br>
> >>> Archive for root<br>
> >> //pcitdi10.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common<br>
> >>> synchronizing roots<br>
> >> //pcitdi10.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common,<br>
> >>> //pcitdi10.cern.<wbr>ch//home/<wbr>zs<br>
> >>> Written at 2007-09-04 at 15:01:30<br>
> >>><br>
> >>> strings ar34d7b618ce27e1cc3<wbr>1527fcce3940f7d | head -3<br>
> >>> Unison archive format 22<br>
> >>> Archive for root //pcitdi10.cern.<wbr>ch//home/<wbr>zs \
synchronizing roots<br> > >>> \
//pcitdi10.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common,<br> > \
>>> //pcitdi10.cern.<wbr>ch//home/<wbr>zs<br> > >>> Written at \
2007-09-04 at 15:01:30<br> > >>><br>
> >>> strings arcc21948e8f9896b0c<wbr>c8a8798135ad5f3|<wbr>head -3<br>
> >>> Unison archive format 22<br>
> >>> Archive for root //lxplus.cern.<wbr>ch//home/<wbr>zs synchronizing \
roots<br> > >>> \
//lxplus.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common,<br> > \
>>> //lxplus.cern.<wbr>ch//home/<wbr>zs<br> > >>> Written at \
2007-09-04 at 15:22:46<br> > >>><br>
> >>> So these ar* files *remember* how the synchronization was \
made.<br> > >>> Note<br>
> >> that<br>
> >>> the ROOT /home/zs has the wrong machine name associated with \
it,<br> > >>> it should be //pcitdi10.cern.<wbr>ch/ and *not* \
//lxplus.cern.<wbr>ch/, this<br> > >>> *must* be an error in unison \
IMHO.<br> > >>><br>
> >>> 3. This step will generat the error, consistently repeatable:<br>
> >>><br>
> >>> I go now to another machine 'pcitpb12', which has an 'ssh' \
access<br> > >>> to 'lxplus', so I should be able to synchronize the \
AFS ROOT<br> > >>> from lxplus with my ROOT on 'pcitpb12'.<br>
> >>> More precisely, I execute the following on 'pcitpb12':<br>
> >>><br>
> >>>> unison zs_common $HOME <a \
href="ssh://sekera@lxplus.cern.ch/$AFS/w0/common">ssh://sekera@<wbr>lxplus.cern.<wbr>ch/$AFS/w0/<wbr>common</a><br>
> >>><br>
> >>> This is *exactly* the same command as in the 2. case above, \
the<br> > >>> difference being that this time my $HOME ROOT in on \
'pcitpb12'<br> > >>> (where the unison command is executed). It so \
happens that<br> > >>> $HOME=/home/<wbr>zs on both 'pcitpb12' and \
'pcitdi10' (comparing still<br> > >>> case 2 and 3) but it shouldn't be \
an issue..<br> > >>><br>
> >>> The command displays this:<br>
> >>><br>
> >>> Connected \
[//lxplus.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common -<br> > \
><br> > >>> //lxplus.cern.<wbr>ch//home/<wbr>zs]<br>
> >>><br>
> >>> Which is identical to the case above except this time the HOME<br>
> ROOT<br>
> >>> should read //pcitpb12.cern.<wbr>ch/ and *not* \
//lxplus.cern.<wbr>ch/.<br> > Again,<br>
> >>> lxplus has no '/home/zs' directory on it.<br>
> >>><br>
> >>> And now the final error, unison will display the following<br>
> message:<br>
> >>><br>
> >>> ------------<wbr>---------<wbr>---------<wbr>---------<wbr>---------<wbr>---------<wbr>-<br>
> >>> Fatal error:<br>
> >>> Warning: inconsistent state.<br>
> >>> The archive file is missing on some hosts.<br>
> >>> For safety, the remaining copies should be deleted.<br>
> >>> Archive arcc21948e8f9896b0c<wbr>c8a8798135ad5f3 on host \
lxplus.cern.<wbr>ch<br> > >> is<br>
> >>> MISSING.<br>
> >>> Archive ar7cf2d2aef5c0de5c9<wbr>4288b65c0694ac0 on host \
lxplus.cern.<wbr>ch<br> > >> should<br>
> >>> be<br>
> >>> DELETED.<br>
> >>> Please delete archive files as appropriate and try again.<br>
> >>> ------------<wbr>---------<wbr>---------<wbr>---------<wbr>---------<wbr>---------<wbr>-<br>
> >>> A few comments to this message:<br>
> >>><br>
> >>> a. Indeed, there is no arcc* file on lxplus.cern.<wbr>ch.<br>
> >>> The only ar* file that's there is:<br>
> >> ar7cf2d2aef5c0de5c9<wbr>4288b65c0694ac0<br>
> >>> it says:<br>
> >>> strings ar7cf2d2aef5c0de5c9<wbr>4288b65c0694ac0 |head -3<br>
> >>> Unison archive format 22<br>
> >>> Archive for root<br>
> >> //lxplus.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common<br>
> >>> synchronizing roots<br>
> >>> //lxplus.cern.<wbr>ch//afs/cern.<wbr>ch/user/s/<wbr>sekera/w0/<wbr>common,<br>
> >>> //lxplus.cern.<wbr>ch//home/<wbr>zs<br>
> >>> Written at 2007-09-04 at 15:22:46<br>
> >>><br>
> >>> Again the HOME root is wrong, so it cannot be determined \
how<br> > the<br>
> >> file<br>
> >>> was generated (which ROOTs were synchronized)<wbr>, though we \
know<br> > it<br>
> >> is<br>
> >>> the result on run 2 above.<br>
> >>><br>
> >>> b. The ar7c* is indeed on lxplus as noted above, but it should \
be<br> > >> perfectly<br>
> >>> legitimate (perhaps it would be if the HOME ROOT was \
correct).<br> > >>><br>
> >>> c. If I indeed proceed as requested in the error message \
(delete<br> > >>> the<br>
> >>> file and restart unison, it will make the "standard" \
initial<br> > run<br>
> >>> ('no archives were found for these roots...') and the \
unison<br> > >>> will<br>
> >> run.<br>
> >>><br>
> >>> However, next time, when I want to synchronize from another<br>
> >> machine<br>
> >>> and ROOT is that AFS ROOT, I will get the same error, so I \
have<br> > >> to<br>
> >>> always delete all ar* files to be able to run, so there is \
in<br> > >>> fact no synchronization per say.<br>
> >>><br>
> >>> For completeness, in my 'zs_common.prf' file I have a statement \
to<br> > >> igonre<br>
> >>> .unison/ar* files (as suggested in unison user manual), don't<br>
> >>> know if<br>
> >>> it is relevent to this case.<br>
> >>><br>
> >>> Has anybody run into such problems? Is it me who is doing \
something<br> > >>> wrong or is this a genuaine unison bug (as I tend to \
believe)?<br> > >>><br>
> >>> For developers: I am ready to run any test you may wish, the<br>
> problem<br>
> >>> is perfectly reproducible with steps above, it only takes some<br>
> time.<br>
> >>><br>
> >>> Best regards,<br>
> >>><br>
> >>> ---Zdenek<br>
> >>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Yahoo! Groups Links<br>
> ><br>
> ><br>
> ><br>
<br>
</p>
</div>
<!--~-|**|PrettyHtmlStart|**|-~-->
<span width="1" style="color: white;">__._,_.___</span>
<!-- Start the section with Message In topic -->
<div id="ygrp-actbar">
<span class="left">
<a href="http://groups.yahoo.com/group/unison-users/message/6539;_ylc=X3oDMT \
MzYmczMmIwBF9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEbXNnSWQDNjYzOARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzExOTE1MDQzOTEEdHBjSWQDNjUzOQ--">
Messages in this topic </a> (<span class="bld">0</span>)
</span>
<a href="http://groups.yahoo.com/group/unison-users/post;_ylc=X3oDMTJvbmJnajBt \
BF9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEbXNnSWQDNjYzOARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzExOTE1MDQzOTE-?act=reply&messageNum=6638">
<span class="bld">
Reply </span> (via web post)
</a> |
<a href="http://groups.yahoo.com/group/unison-users/post;_ylc=X3oDMTJkODdqanRt \
BF9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDbnRwYwRzdGltZQMxMTkxNTA0Mzkx" \
class="bld"> Start a new topic </a>
</div>
<!------- Start Nav Bar ------>
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-vitnav">
<a href="http://groups.yahoo.com/group/unison-users/messages;_ylc=X3oD \
MTJkN2xtbGg0BF9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDbXNncwRzdGltZQMxMTkxNTA0Mzkx">Messages</a> \
| <a href="http://groups.yahoo.com/group/unison-users/database;_ylc=X3o \
DMTJiOXRjMWdvBF9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDZGIEc3RpbWUDMTE5MTUwNDM5MQ--">Database</a> \
</div>
<!-- |**|end egp html banner|**| -->
<div id="ygrp-grft">
</div>
<!-- yahoo logo -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-ft">
<a href="http://groups.yahoo.com/;_ylc=X3oDMTJjaHFybGs2BF9TAzk3MzU5NzE0BGdycElkA \
zQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDZ2ZwBHN0aW1lAzExOTE1MDQzOTE-">
<img src="http://us.i1.yimg.com/us.yimg.com/i/yg/img/logo/ma_grp_160.gif" \
height="15" width="106" border="0" alt="Yahoo! Groups"></a> <br> <a \
href="http://groups.yahoo.com/group/unison-users/join;_ylc=X3oDMTJlaGlhcWczBF9TAzk3MzU \
5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDc3RuZ3MEc3RpbWUDMTE5MTUwNDM5MQ--">Change \
settings via the Web</a> (Yahoo! ID required) <br> Change settings via email: <a \
href="mailto:unison-users-digest@yahoogroups.com?subject=Email Delivery: \
Digest">Switch delivery to Daily Digest</a> | <a href = \
"mailto:unison-users-traditional@yahoogroups.com?subject=Change Delivery Format: \
Traditional">Switch format to Traditional</a> <br>
<a href="http://groups.yahoo.com/group/unison-users;_ylc=X3oDMTJjYnY1dHFvBF9TAzk \
3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA2Z0cgRzbGsDaHBmBHN0aW1lAzExOTE1MDQzOTE-">
Visit Your Group
</a> |
<a href="http://docs.yahoo.com/info/terms/">
Yahoo! Groups Terms of Use </a> |
<a href="mailto:unison-users-unsubscribe@yahoogroups.com?subject=">
Unsubscribe </a>
</div> <!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id="ygrp-sponsor" style="width:140px;float: left; clear: none; margin-left: \
5px; background:white; margin-bottom:25px ;position:absolute; top:0; right: 0;"> \
<!-- Network content -->
<!-- Start vitality -->
<div id="ygrp-vital">
<div id="vithd">Recent Activity</div>
<ul style="list-style-type:none; padding: 0; margin: 2px 0;">
<li style="clear: both;">
<div class="ct" style="float: right;"><span \
style="display:none"> </span>7</div> <div class="cat"><a \
href="http://groups.yahoo.com/group/unison-users/members;_ylc=X3oDMTJlYmVlZTlrBF9TAzk3 \
MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA3Z0bARzbGsDdm1icnMEc3RpbWUDMTE5MTUwNDM5MQ--">New \
Members</a></div> </li>
</ul>
<a href="http://groups.yahoo.com/group/unison-users;_ylc=X3oDMTJkNDlxcnNoB \
F9TAzk3MzU5NzE0BGdycElkAzQ3OTc2NwRncnBzcElkAzE3MDUwMDQ3MjYEc2VjA3Z0bARzbGsDdmdocARzdGltZQMxMTkxNTA0Mzkx">
Visit Your Group </a>
</div>
<!-- Network content -->
<div id="nc">
<div class="ad">
<div id="hd1">Yahoo! Finance</div>
<p><a href="http://us.ard.yahoo.com/SIG=12j64tsct/M=493064.10729649.11333340.8674578/D \
=groups/S=1705004726:NC/Y=YAHOO/EXP=1191511591/A=4507179/R=0/SIG=12de4rskk/*http://us.rd.yahoo.com/evt=50284/*http://finance.yahoo.com/personal-finance">It's \
Now Personal</a></p> <p>Guides, news,</p>
<p>advice & more.</p> </div>
<div class="ad">
<div id="hd1">Search Ads</div>
<p><a href="http://us.ard.yahoo.com/SIG=12jijcbj3/M=493064.10729656.11333347.8674578/D \
=groups/S=1705004726:NC/Y=YAHOO/EXP=1191511591/A=3848641/R=0/SIG=1312g85fq/*http://sea \
rchmarketing.yahoo.com/arp/srchv2.php?o=US2003&cmp=Yahoo&ctv=Groups2&s=Y&s2=&s3=&b=50">Get \
new customers.</a></p> <p>List your web site</p>
<p>in Yahoo! Search.</p> </div>
<div class="ad">
<div id="hd1">Yahoo! Groups</div>
<p><a href="http://us.ard.yahoo.com/SIG=12j3joq10/M=493064.11135488.11710474.8674578/D \
=groups/S=1705004726:NC/Y=YAHOO/EXP=1191511591/A=4776364/R=0/SIG=11mj2s6kj/*http://advision.webevents.yahoo.com/green/index.html">Going \
Green</a></p> <p>Share your passion</p>
<p>for the planet.</p> </div>
</div>
</div> <!-- |**|end egp html banner|**| -->
<div style="clear:both; color: #FFF; font-size:1px;">.</div>
</div> <img src="http://geo.yahoo.com/serv?s=97359714/grpId=479767/grpspId=1705004726/msgId=6638/stime=1191504391/nc1=4507179/nc2=3848641/nc3=4776364" \
width="1" height="1"> <br>
<span style="color: white;">__,_._,___</span>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</body>
<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type="text/css">
<!--
#ygrp-mkp{
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 14px 0px;
padding: 0px 14px;
}
#ygrp-mkp hr{
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd{
color: #628c2a;
font-size: 85%;
font-weight: bold;
line-height: 122%;
margin: 10px 0px;
}
#ygrp-mkp #ads{
margin-bottom: 10px;
}
#ygrp-mkp .ad{
padding: 0 0;
}
#ygrp-mkp .ad a{
color: #0000ff;
text-decoration: none;
}
-->
</style>
</head>
<head>
<style type="text/css">
<!--
#ygrp-sponsor #ygrp-lc{
font-family: Arial;
}
#ygrp-sponsor #ygrp-lc #hd{
margin: 10px 0px;
font-weight: bold;
font-size: 78%;
line-height: 122%;
}
#ygrp-sponsor #ygrp-lc .ad{
margin-bottom: 10px;
padding: 0 0;
}
-->
</style>
</head>
<head>
<style type="text/css">
<!--
#ygrp-mlmsg {font-size:13px; font-family: \
arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;} #ygrp-mlmsg table \
{font-size:inherit;font:100%;} #ygrp-mlmsg select, input, textarea {font:99% \
arial,helvetica,clean,sans-serif;} #ygrp-mlmsg pre, code {font:115% \
monospace;*font-size:100%;} #ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family: Georgia;
}
#ygrp-text p{
margin: 0 0 1em 0;
}
#ygrp-tpmsgs{
font-family: Arial;
clear: both;
}
#ygrp-vitnav{
padding-top: 10px;
font-family: Verdana;
font-size: 77%;
margin: 0;
}
#ygrp-vitnav a{
padding: 0 1px;
}
#ygrp-actbar{
clear: both;
margin: 25px 0;
white-space:nowrap;
color: #666;
text-align: right;
}
#ygrp-actbar .left{
float: left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family: Verdana;
font-size: 77%;
padding: 15px 0;
}
#ygrp-ft{
font-family: verdana;
font-size: 77%;
border-top: 1px solid #666;
padding: 5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom: 10px;
}
#ygrp-vital{
background-color: #e0ecee;
margin-bottom: 20px;
padding: 2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size: 77%;
font-family: Verdana;
font-weight: bold;
color: #333;
text-transform: uppercase;
}
#ygrp-vital ul{
padding: 0;
margin: 2px 0;
}
#ygrp-vital ul li{
list-style-type: none;
clear: both;
border: 1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight: bold;
color: #ff7900;
float: right;
width: 2em;
text-align:right;
padding-right: .5em;
}
#ygrp-vital ul li .cat{
font-weight: bold;
}
#ygrp-vital a{
text-decoration: none;
}
#ygrp-vital a:hover{
text-decoration: underline;
}
#ygrp-sponsor #hd{
color: #999;
font-size: 77%;
}
#ygrp-sponsor #ov{
padding: 6px 13px;
background-color: #e0ecee;
margin-bottom: 20px;
}
#ygrp-sponsor #ov ul{
padding: 0 0 0 8px;
margin: 0;
}
#ygrp-sponsor #ov li{
list-style-type: square;
padding: 6px 0;
font-size: 77%;
}
#ygrp-sponsor #ov li a{
text-decoration: none;
font-size: 130%;
}
#ygrp-sponsor #nc{
background-color: #eee;
margin-bottom: 20px;
padding: 0 8px;
}
#ygrp-sponsor .ad{
padding: 8px 0;
}
#ygrp-sponsor .ad #hd1{
font-family: Arial;
font-weight: bold;
color: #628c2a;
font-size: 100%;
line-height: 122%;
}
#ygrp-sponsor .ad a{
text-decoration: none;
}
#ygrp-sponsor .ad a:hover{
text-decoration: underline;
}
#ygrp-sponsor .ad p{
margin: 0;
}
o{font-size: 0; }
.MsoNormal{
margin: 0 0 0 0;
}
#ygrp-text tt{
font-size: 120%;
}
blockquote{margin: 0 0 0 4px;}
.replbq{margin:4}
-->
</style>
</head>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</html><!--End group email -->
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic