headers
fjrm | 3 Aug 2002 04:25
Picon
Favicon

Error in setting permissions

Coming back to using Unison after some long.. months off.
Using 2.9.1, getting the error
Failed with exception Util.Transient("Error in setting permissions:\nOperation not permitted [chmod(/usr/backups/carive_backup.tar.bz2.cpt)]")
Failed: Error in setting permissions:

I don't understand why unison is reporting this error. This is the source file. 
The rights of the source files are 664 and the user over ssh is on the group that the source files belong to.

Why is Unison trying to make changes to the source files?

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 3 comments |
headers
Benjamin C. Pierce | 5 Aug 2002 17:09
Favicon

Re: multi-threaded transport sub-system

> Is there a switch to turn the "multi-threaded transport sub-system" off (ie.
> back to single-thread) ?
> {alternately a switch to control the MAX number of worker/transport threads}

Not in 2.9.1, but I've just added a new preference ("maxthreads") to do
this.  You can either wait till tomorrow and grab and recompile the
developer tarball, or else manually patch the source by changing

  let actionReg = Lwt_util.make_region 50

to

  let actionReg = Lwt_util.make_region 1

in transport.ml.

    Benjamin

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
Benjamin C. Pierce | 5 Aug 2002 17:27
Favicon

Re: "rsyncfailure" error message

> I am using unison 2.8.1 between redhat linux 7.1 and solaris 5.6. When 
> updating some files (mostly powerpoint and excel), it issues a mysterious 
> message
> "Failed: rsyncfailure".
> It does not happen for all such files, but once it starts happening for one of 
> them, it happens forever.
> Moreover, the file is correctly mirrored, so the failure is not actually a 
> failure.
> Does anybody know why?

Do you mean that the contents of the file after synchronization is the
same on both replicas, yet unison still complains about rsync failure on
the next sync, even if the file has not changed in between?  

In any case, a workaround is to set the 'rsync' preference to false.

(This preference is currently undocumented, but since several people have
run into intermittent problems with rsync I'll make it visible in the
next release.) 

    Benjamin

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 1 comment |
headers
Benjamin C. Pierce | 5 Aug 2002 17:38
Favicon

Re: feature request: undo /

> When manually going through a list of proposed propogations in the
> graphical system, it would be nice to be able to undo the effect of
> pressing "/", i.e., to revert from "?" to whichever direction unison
> first recommended.
> 
> (I noticed this when holding down "/" to skip past 100 files.  I
> overshot the end of this list and found myself unable to remember which
> was Unison's suggested direction for the subsequent files I erroneously
> marked "?".)

Yes.  The graphical UI helps with this by displaying items where you've
changed Unison's default recommendation in a different color.  

FFTH...  :-)  

(Seriously: the Uitext module is really pretty simple.)

     B

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
Benjamin C. Pierce | 5 Aug 2002 21:43
Favicon

Re: Error in setting permissions

> Using 2.9.1, getting the error
> Failed with exception Util.Transient("Error in setting permissions:\nOperation not permitted [chmod(/usr/backups/carive_backup.tar.bz2.cpt)]")
> Failed: Error in setting permissions:
> 
> I don't understand why unison is reporting this error. This is the source file. 
> The rights of the source files are 664 and the user over ssh is on the group that the source files belong to.
> 
> Why is Unison trying to make changes to the source files?

Are you sure that Unison considered this file to be the source -- e.g.,
did the user interface tell you that it was going to transfer the file in
the other direction?  And are you sure the error message was coming from
the machine you thought it was?  

    B
Permalink | Reply | 2 comments |
headers
Francisco Reyes | 6 Aug 2002 00:32
Picon
Favicon

Re: Error in setting permissions

- "Benjamin C. Pierce" <bcpierce <at> saul.cis.upenn.edu> wrote:
> > Using 2.9.1, getting the error
> > Failed with exception Util.Transient("Error in setting
> permissions:\nOperation not permitted
> [chmod(/usr/backups/carive_backup.tar.bz2.cpt)]")
> > Failed: Error in setting permissions:
.....
> > Why is Unison trying to make changes to the source
> files?
> 
> Are you sure that Unison considered this file to be the
> source

The files didn't even exist on the other machine. Moreover
the machine where the files were coming from was listed as 
"preferred".

> the other direction?  And are you sure the error message
> was coming from the machine you thought it was?  

How could I tell?
If I set the files to 666 in the source it didn't report
any warnings. If I set it to 664 then it gave the errors I posted.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Luciano Lavagno | 5 Aug 2002 18:08
Picon

Re: "rsyncfailure" error message


bcpierce <at> saul.cis.upenn.edu said:
> Do you mean that the contents of the file after synchronization is the
> same on both replicas, yet unison still complains about rsync failure
> on the next sync, even if the file has not changed in between?   
Yes, exactly.

> In any case, a workaround is to set the 'rsync' preference to false. 
Thanks, that worked!!!
Ciao!!!
Luciano 
--

-- 
Luciano Lavagno       http://polimage.polito.it/~lavagno    lavagno <at> polito.it
Cell. US +1-510-8515095         Cadence Berkeley +1-510-6472810 (fax 4860205)
Cell. EU +39-348-6003714  Politecnico di Torino +39-011-5644150 (fax 5644099)
Dipartimento di Elettronica, Corso Duca degli Abruzzi 24, 10129 Torino, Italy
Permalink | Reply | 0 comments |
headers
Ruslan Ermilov | 6 Aug 2002 10:06

Losing data with unison 2.9.1

Hi!

(I wrote about this to unison-help <at> cis.upenn.edu on Aug 1, but never
heard back, hopefully "yet".)

We are losing data with Unison 2.9.1.  The symptoms are as follows:

Unison decides that the file F of size N is to be copied from local
replica L to remote replica R (with F of size O, O < N).  Unison
reports that the copy was successful.  On the next run (in 20 minutes
after this run is finished), Unison sees the file F in local replica L
as ``unchanged'' (OK) and F in remote replica R as ``changed'' and
of the old size O.  So it looks like Unison did not actually do the
copy on the previous run, but instead it just screws F's modtime in
remote replica (as could be seen from stderr logs).

The replicas in question were CVS repositories, and remote repository
was not modified during these 20 minutes (I know for sure).  Well,
this particular part of the CVS tree is never changed on the remote
site.  The replicas are about 2G in size at the moment.

We synchronize our CVS, Gnats and file archives through Unison.  We
did not have these problems with 2.7.1, but 2.9.1 has many nice new
features (our favourite is ``xferbycopying'') we would like to use.

We synchronize the following attributes between replicas:

: # Default preferences file
: #
: # $Sunbay: sun-net/hosts/whale/local/etc/unison/default.prf,v 1.1 2002/07/01 08:07:34 ru Exp $
(Continue reading)

Permalink | Reply | 13 comments |
headers
Ruslan Ermilov | 6 Aug 2002 15:38

Concurrency problems with Unison

Hi!

I have finally managed to find the cause of mysterious exceptions
like the below:

: Failed: Error in setting file ownership:
: No such file or directory [chown(/data/cvsroot/ret-kof/doc/.#qa.0.unison.tmp/retkof_asspec.doc,v)]

In our scenario, we have 5 boxes synchronizing /data/cvsroot replicas,
besides others.  For our example, it is enough to consider three hosts.
Host A starts the synchronization session with host B and transfers a
large directory.  While this operation is in progress, host B initiates
the synchronization session with host C.  This unison process blows
away .unison.tmp directory (currently in use for A<->B) and finishes
reporting "Nothing to do: replicas have not been changed since last sync."

On host A, this results in:

: Contacting server...
: Looking for changes
[...]
:   ret-kof
:   ret-kof/doc
[...]
:   Waiting for changes from server
: Reconciling changes
: 
: local          octopus.s...       
: new dir  ---->            ret-kof/doc/qa  
: local        : new dir
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruslan Ermilov | 6 Aug 2002 14:36

Uncaught exception in path.ml

Hi!

Unison 2.9.1.  FreeBSD 4.6.  Attempting to symlink ~/.unison/backup to
another (real) directory results in the following uncaught exception:

: $ ls -ld ~/.unison/*backup
: lrwx------  1 ru  sunbay   10 Aug  6 15:22 /home/ru/.unison/backup -> realbackup
: drwx------  2 ru  sunbay  512 Aug  6 15:22 /home/ru/.unison/realbackup
: $ unison -batch -backup='Name *' /tmp/replica1 /tmp/replica2
: Contacting server...
: Looking for changes
: Reconciling changes
: 
: replica1       replica2           
: deleted  ---->            a  
: replica1     : deleted
: replica2     : unchanged file   
:   modified at 15:22 on  6 Aug, 2002  size 0         rw-------
: Propagating updates
: 
: 
: UNISON started propagating changes at 15:26:04 on 06 Aug 2002
: [BGN] Deleting a
:   from /tmp/replica2
: Uncaught exception File "/usr/ports/net/unison/work/unison-2.9.1/path.ml", line 0, characters
1785-1797: Assertion failed

OTOH, Unison follows ~/.unison if it's symlinked, and I use this feature
when using SSH as a transport.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane