Hi!

I've just installed unison 2.1 on linux 2.2.15 (redhat 6.2) and noticed
that the text-mode doesn't work for me:

----------
> unison -ui text
bergolth@...'s password:
Looking for changes
Looking for changes [Waiting for changes from server]
Reconciling changes
Checking for conflicts

local          strike.wu...
          <---- new file   tmp/urxn/urxn4
Uncaught exception Sys_blocked_io
----------

Using -dumbtty also doesn't work.

I have built caml from the ocaml-3.00-3 Source RPM from Rawhide.

Any hints?

Cheers,
--leo

P.S.: Synchronizing modification times would be a _great_ improvement!
       (Yes, I have read the TODO list.)

-----------------------------------------------------------------------
Alexander (Leo) Bergolth                          leo@...
WU-Wien - Zentrum fuer Informatikdienste       http://leo.wu-wien.ac.at
Info Center
                  Computers are like air conditioners -
            they stop working properly when you open Windows

"Benjamin C. Pierce" wrote:

> >   First, the gzipped versions of the programs differ from the unzipped
> > versions.  The gzipped versions end up longer after you unzip them, plus
> > gzip would complain if they were truncated, so I'm assuming that the gzipped
> > versions are correct.
>
> Are you sure?  I just tried unzipping all the .gz files, and they seem to
> come out identical to the originals.

Crap.  Netscape must have screwed me up.  Now it all comes out clean.

> >   Second, the client-server mode seems to be utterly broken.  If the server
> > is not there then the client complains.  But if the server is running then
> > both sides end up hanging---it is as if the server never actually accepts
> > the connection.  Running with "-debug remote" on the server prints out
> > nothing beyond the "starting" message.
>
> Can you try with '-debug verbose' on both sides?

OK, this was my mistake too.  I was running the old version on the server side!

I apologize for wasting everyone's time.

Luke

"Benjamin C. Pierce" wrote:

> The incremented major version number signals that we believe this
> release is pretty stable...  Both courageous and conservative users
> are now welcome to upgrade!

   I tried to upgrade, but it isn't working for me.  I am running Linux.

   First, the gzipped versions of the programs differ from the unzipped
versions.  The gzipped versions end up longer after you unzip them, plus
gzip would complain if they were truncated, so I'm assuming that the gzipped
versions are correct.

   Second, the client-server mode seems to be utterly broken.  If the server
is not there then the client complains.  But if the server is running then
both sides end up hanging---it is as if the server never actually accepts
the connection.  Running with "-debug remote" on the server prints out
nothing beyond the "starting" message.

   I have rolled back to 1.231, which continues to work fine.  Am I missing
something with 2.1?

Luke

On Thu, Jun 08, 2000 at 03:50:21PM -0700, Luke Blanshard wrote:
> For the absent-minded among us, would you mind including a URL to the
> download site?

You will find it on http://www.cis.upenn.edu/~bcpierce/unison/

-- Jerome

For the absent-minded among us, would you mind including a URL to the
download site?

Thanks,
Luke

"Benjamin C. Pierce" wrote:

> The incremented major version number signals that we believe this
> release is pretty stable...  Both courageous and conservative users
> are now welcome to upgrade!
>
>         Share and enjoy,
>
>             The Unison Team
>             (Sylvain, Jerome, Trevor, Benjamin)

The incremented major version number signals that we believe this
release is pretty stable...  Both courageous and conservative users
are now welcome to upgrade!

         Share and enjoy,

             The Unison Team
             (Sylvain, Jerome, Trevor, Benjamin)



    Changes since 1.292:
      * Reduced memory footprint (this is especially important during the
        first run of unison, where it has to gather information about all
        the files in both repositories).
      * Fixed a bug that would cause the socket server under NT to fail
        after the client exits.
      * Added a SHIFT modifier to the Ignore menu shortcut keys in GTK
        interface (to avoid hitting them accidentally).

    Changes since 1.231:
      * Tunneling over ssh is now supported in the Windows version. See
        the installation section of the manual for detailed instructions.
      * The transport subsystem now includes an implementation of the
        rsync protocol, built by Sylvain Gommier and Norman Ramsey. This
        protocol achieves much faster transfers when only a small part of
        a large file has been changed by sending just diffs. The rsync
        feature is off by default in the current version. Use the -rsync
        switch to turn it on. (Nb. We still have a lot of tuning to do:
        you may not notice much speedup yet.)
      * We're experimenting with a multi-threaded transport subsystem,
        written by Jerome Vouillon. The downloadable binaries are still
        single-threaded: if you want to try the multi-threaded version,
        you'll need to recompile from sources. (Say make THREADS=true.)
        Native thread support from the compiler is required. Use the
        option -threads N to select the maximal number of concurrent
        threads (default is 5). Multi-threaded and single-threaded
        clients/servers can interoperate.
      * A new GTK-based user interface is now available, thanks to Jacques
        Garrigue. The Tk user interface still works, but we'll be shifting
        development effort to the GTK interface from now on.
      * OCaml 3.00 is now required for compiling Unison from sources. The
        modules uitk and myfileselect have been changed to use labltk
        instead of camltk. To compile the Tk interface in Windows, you
        must have ocaml-3.00 and tk8.3. When installing tk8.3, put it in
        c:\Tcl rather than the suggested c:\Program Files\Tcl, and be sure
        to install the headers and libraries (which are not installed by
        default).
      * Added a new -addversionno switch, which causes unison to use
        unison-<currentversionnumber> instead of just unison as the remote
        server command. This allows multiple versions of unison to coexist
        conveniently on the same server: whichever version is run on the
        client, the same version will be selected on the server.

    Changes since 1.219:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * This version fixes several annoying bugs, including:
           + Some cases where propagation of file permissions was not
             working.
           + umask is now ignored when creating directories
           + directories are create writable, so that a read-only
             directory and its contents can be propagated.
           + Handling of warnings generated by the server.
           + Synchronizing a path whose parent is not a directory on both
             sides is now flagged as erroneous.
           + Fixed some bugs related to symnbolic links and nonexistant
             roots.
                o When a change (deletion or new contents) is propagated
                  onto a 'follow'ed symlink, the file pointed to by the
                  link is now changed. (We used to change the link itself,
                  which doesn't fit our assertion that 'follow' means the
                  link is completely invisible)
                o When one root did not exist, propagating the other root
                  on top of it used to fail, becuase unison could not
                  calculate the working directory into which to write
                  changes. This should be fixed.
      * A human-readable timestamp has been added to Unison's archive
        files.
      * The semantics of Path and Name regular expressions now correspond
        better.
      * Some minor improvements to the text UI (e.g. a command for going
        back to previous items)
      * The organization of the export directory has changed --- should be
        easier to find / download things now.

    Changes since 1.200:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * This version has not been tested extensively on Windows.
      * Major internal changes designed to make unison safer to run at the
        same time as the replicas are being changed by the user.
      * Internal performance improvements.

    Changes since 1.190:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * A number of internal functions have been changed to reduce the
        amount of memory allocation, especially during the first
        synchronization. This should help power users with very big
        replicas.
      * Reimplementation of low-level remote procedure call stuff, in
        preparation for adding rsync-like smart file transfer in a later
        release.
      * Miscellaneous bug fixes.

    Changes since 1.180:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * Fixed some small bugs in the interpretation of ignore patterns.
      * Fixed some problems that were preventing the Windows version from
        working correctly when click-started.
      * Fixes to treatment of file permissions under Windows, which were
        causing spurious reports of different permissions when
        synchronizing between windows and unix systems.
      * Fixed one more non-tail-recursive list processing function, which
        was causing stack overflows when synchronizing very large
        replicas.

    Changes since 1.169:
      * The text user interface now provides commands for ignoring files.
      * We found and fixed some more non-tail-recursive list processing
        functions. Some power users have reported success with very large
        replicas.
      * INCOMPATIBLE CHANGE: Files ending in .tmp are no longer ignored
        automatically. If you want to ignore such files, put an
        appropriate ignore pattern in your profile.
      * INCOMPATIBLE CHANGE: The syntax of ignore and follow patterns has
        changed. Instead of putting a line of the form

                  ignore = <regexp>
        in your profile (.unison/default.prf), you should put:

                  ignore = Regexp <regexp>
        Moreover, two other styles of pattern are also recognized:

                  ignore = Name <name>
        matches any path in which one component matches <name>, while

                  ignore = Path <path>
        matches exactly the path <path>.
        Standard ``globbing'' conventions can be used in <name> and
        <path>:
           + a ? matches any single character except /
           + a * matches any sequence of characters not including /
           + [xyz] matches any character from the set {x, y, z }
           + {a,bb,ccc} matches any one of a, bb, or ccc.
        See the user manual for some examples.

    Changes since 1.146:
      * Some users were reporting stack overflows when synchronizing huge
        directories. We found and fixed some non-tail-recursive list
        processing functions, which we hope will solve the problem. Please
        give it a try and let us know.
      * Major additions to the documentation.

    Changes since 1.142:
      * Major internal tidying and many small bugfixes.
      * Major additions to the user manual.
      * Unison can now be started with no arguments -- it will prompt
        automatically for the name of a profile file containing the roots
        to be synchronized. This makes it possible to start the graphical
        UI from a desktop icon.
      * Fixed a small bug where the text UI on NT was raising a 'no such
        signal' exception.

    Changes since 1.139:
      * The precompiled windows binary in the last release was compiled
        with an old OCaml compiler, causing propagation of permissions not
        to work (and perhaps leading to some other strange behaviors we've
        heard reports about). This has been corrected. If you're using
        precompiled binaries on Windows, please upgrade.
      * Added a -debug command line flag, which controls debugging of
        various modules. Say -debug XXX to enable debug tracing for module
        XXX, or -debug all to turn on absolutely everything.
      * Fixed a small bug where the text UI on NT was raising a 'no such
        signal' exception.

    Changes since 1.111:
      * INCOMPATIBLE CHANGE: The names and formats of the preference files
        in the .unison directory have changed. In particular:
           + the file ``prefs'' should be renamed to default.prf
           + the contents of the file ``ignore'' should be merged into
             default.prf. Each line of the form REGEXP in ignore should
             become a line of the form ignore = REGEXP in default.prf.
      * Unison now handles permission bits and symbolic links. See the
        manual for details.
      * You can now have different preference files in your .unison
        directory. If you start unison like this

              unison profilename
        (i.e. with just one ``anonymous'' command-line argument), then the
        file ~/.unison/profilename.prf will be loaded instead of
        default.prf.
      * Some improvements to terminal handling in the text user interface
      * Added a switch -killServer that terminates the remote server
        process when the unison client is shutting down, even when using
        sockets for communication. (By default, a remote server created
        using ssh/rsh is terminated automatically, while a socket server
        is left running.)
      * When started in 'socket server' mode, unison prints 'server
        started' on stderr when it is ready to accept connections. (This
        may be useful for scripts that want to tell when a socket-mode
        server has finished initalization.)
      * We now make a nightly mirror of our current internal development
        tree, in case anyone wants an up-to-the-minute version to hack
        around with.
      * Added a file CONTRIB with some suggestions for how to help us make
        Unison better.


Documentation topic news not recognized:
Type "unison -doc topics" for a list

> Working under windows NT, I encounter problems with the case of
> files. Its amazing how easy it is to 'goof' up the case of a file
> name for directories that are under unison sync control. (My zip
> drive seems to have trouble preserving case. If I move
> a file there and back, it often goobers up the case.) Unison has a
> real problem fixing the problem. (probably from their unix heritage)
> I end up correcting it by hand. Would it be possible to specify case
> insensitive operation? Or perhaps allow me to drive the case tool to
> fix it.
>
> Is there another solution?

Dealing with this is one of the things at the top of our priority
list.  It's actually surprisingly hard to see what is the right
behavior for Unison here, since we need to handle both the
Windows<->Windows and the Windows<->Unix case correctly.

      B

> I have several sections of my computer synchronized. I end up
> sync'ing a couple of them one after another. Is there a way to create
> a 'group' of sync lists? Maybe reference a .prf file inside a .prf
> file?
>
> An obvious solution is to create a sync session for a large part of
> the disk and exclude areas that don't need to be included. However
> that would be a pain.

The -path option is probably the best way to do this.  See the "Using
Unison for all your files" section of the manual.

        B

Sure.  Run rsync once to get the copy synced with the master, then run
unison to keep them up to snuff.

rsync has its own benefits and problems - but it works great for
initially bringing the two copies up-to-date.

Perhaps an rsync-like unidirectional option would be a welcome addition
to unison.

--Yan

kevin.cutts@... wrote:
>
> If I have two directories that are identical and try to sync them, I
> usually get problems that need resolving. Rather than go through the
> hassle of fixing this one file at a time, I usually remove one copy
> and let unison replicate the files. (A tremendous waste of
> bandwidth.) Is there an easier way to resolve this?
>
> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe@onelist.com

--

Think different
	 ride a recumbent
		 use Linux.

If I have two directories that are identical and try to sync them, I
usually get problems that need resolving. Rather than go through the
hassle of fixing this one file at a time, I usually remove one copy
and let unison replicate the files. (A tremendous waste of
bandwidth.) Is there an easier way to resolve this?

Working under windows NT, I encounter problems with the case of
files. Its amazing how easy it is to 'goof' up the case of a file
name for directories that are under unison sync control. (My zip
drive seems to have trouble preserving case. If I move
a file there and back, it often goobers up the case.) Unison has a
real problem fixing the problem. (probably from their unix heritage)
I end up correcting it by hand. Would it be possible to specify case
insensitive operation? Or perhaps allow me to drive the case tool to
fix it.

Is there another solution?

I have several sections of my computer synchronized. I end up
sync'ing a couple of them one after another. Is there a way to create
a 'group' of sync lists? Maybe reference a .prf file inside a .prf
file?

An obvious solution is to create a sync session for a large part of
the disk and exclude areas that don't need to be included. However
that would be a pain.

I could create a script to run them one after another but thats
difficult with the interaction required.

PS This problem is all the fault of the designers. If they hadn't
made the sync operation so useful, I wouldn't have thought of so much
use for the tool.

On Thu, 8 Jun 2000, Benjamin C. Pierce wrote:

> > I have unison working from my desktop to my laptop, but it is not
> > behaving quite the way I expected. I have a number of data files that
> > are recreated (i.e. written as a new file over an existing file of the
> > same name) when I run a program, and I would like to propogate those
> > changes such that the file that was created most recently is copied
> > over to the other computer.
> >
> > Right now, unison flags the file as existing on both machines but
> > requires me to give a direction for the file copy. Is there any way
> > for it to automatically choose the newer file?
>
> I'm not sure I understand precisely the behavior you're seeing, but
> here's one possibility: Unison needs to run one time with both
> replicas in the same state (or at least, ending up in the same state)
> to get its internal records established.  The very first time it runs,
> it will signal a conflict for every file that's different, no matter
> which version is newer.
>
Ah. Now I understand. Sorry for the confusion....

Loren

> I have unison working from my desktop to my laptop, but it is not
> behaving quite the way I expected. I have a number of data files that
> are recreated (i.e. written as a new file over an existing file of the
> same name) when I run a program, and I would like to propogate those
> changes such that the file that was created most recently is copied
> over to the other computer.
>
> Right now, unison flags the file as existing on both machines but
> requires me to give a direction for the file copy. Is there any way
> for it to automatically choose the newer file?

I'm not sure I understand precisely the behavior you're seeing, but
here's one possibility: Unison needs to run one time with both
replicas in the same state (or at least, ending up in the same state)
to get its internal records established.  The very first time it runs,
it will signal a conflict for every file that's different, no matter
which version is newer.

       Benjamin

I have unison working from my desktop to my laptop, but it is not
behaving quite the way I expected. I have a number of data files that
are recreated (i.e. written as a new file over an existing file of the
same name) when I run a program, and I would like to propogate those
changes such that the file that was created most recently is copied
over to the other computer.

Right now, unison flags the file as existing on both machines but
requires me to give a direction for the file copy. Is there any way
for it to automatically choose the newer file?

Thanks,

Loren Frank

We will shortly be announcing a major new release of Unison.  A
beta-test version is now available from the usual place:

         http://www.cis.upenn.edu/~bcpierce/unison/download.html

Courageous users are encouraged to try installing the new release to
help shake out problems (please let us know how it goes, good or
bad!).  Conservative users should wait a few days for the stable
release announcement.

Share and enjoy,

         The Unison Team
         (Sylvain Gommier, Jerome Vouillon, Trevor Jim, Benjamin Pierce)


Here are the main changes in the new version.

    Changes since 1.231:
      * Tunneling over ssh is now supported in the Windows version. See
        the installation section of the manual for detailed instructions.
      * The transport subsystem now includes an implementation of the
        rsync protocol, built by Sylvain Gommier and Norman Ramsey. This
        protocol achieves much faster transfers when only a small part of
        a large file has been changed by sending just diffs. The rsync
        feature is off by default in the current version. Use the -rsync
        switch to turn it on. (Nb. We still have a lot of tuning to do:
        you may not notice much speedup yet.)
      * We're experimenting with a multi-threaded transport subsystem,
        written by Jerome Vouillon. The downloadable binaries are still
        single-threaded: if you want to try the multi-threaded version,
        you'll need to recompile from sources. (Say make THREADS=true.)
        Native thread support from the compiler is required. Use the
        option -threads N to select the maximal number of concurrent
        threads (default is 5). Multi-threaded and single-threaded
        clients/servers can interoperate.
      * A new GTK-based user interface is now available, thanks to Jacques
        Garrigue. The Tk user interface still works, but we'll be shifting
        development effort to the GTK interface from now on.
      * OCaml 3.00 is now required for compiling Unison from sources. The
        modules uitk and myfileselect have been changed to use labltk
        instead of camltk. To compile the Tk interface in Windows, you
        must have ocaml-3.00 and tk8.3. When installing tk8.3, put it in
        c:\Tcl rather than the suggested c:\Program Files\Tcl, and be sure
        to install the headers and libraries (which are not installed by
        default).
      * Added a new -addversionno switch, which causes unison to use
        unison-<currentversionnumber> instead of just unison as the remote
        server command. This allows multiple versions of unison to coexist
        conveniently on the same server: whichever version is run on the
        client, the same version will be selected on the server.

    Changes since 1.219:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * This version fixes several annoying bugs, including:
           + Some cases where propagation of file permissions was not
             working.
           + umask is now ignored when creating directories
           + directories are create writable, so that a read-only
             directory and its contents can be propagated.
           + Handling of warnings generated by the server.
           + Synchronizing a path whose parent is not a directory on both
             sides is now flagged as erroneous.
           + Fixed some bugs related to symnbolic links and nonexistant
             roots.
                o When a change (deletion or new contents) is propagated
                  onto a 'follow'ed symlink, the file pointed to by the
                  link is now changed. (We used to change the link itself,
                  which doesn't fit our assertion that 'follow' means the
                  link is completely invisible)
                o When one root did not exist, propagating the other root
                  on top of it used to fail, becuase unison could not
                  calculate the working directory into which to write
                  changes. This should be fixed.
      * A human-readable timestamp has been added to Unison's archive
        files.
      * The semantics of Path and Name regular expressions now correspond
        better.
      * Some minor improvements to the text UI (e.g. a command for going
        back to previous items)
      * The organization of the export directory has changed --- should be
        easier to find / download things now.

    Changes since 1.200:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * This version has not been tested extensively on Windows.
      * Major internal changes designed to make unison safer to run at the
        same time as the replicas are being changed by the user.
      * Internal performance improvements.

    Changes since 1.190:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * A number of internal functions have been changed to reduce the
        amount of memory allocation, especially during the first
        synchronization. This should help power users with very big
        replicas.
      * Reimplementation of low-level remote procedure call stuff, in
        preparation for adding rsync-like smart file transfer in a later
        release.
      * Miscellaneous bug fixes.

    Changes since 1.180:
      * INCOMPATIBLE CHANGE: Archive format has changed. Make sure you
        synchronize your replicas before upgrading, to avoid spurious
        conflicts. The first sync after upgrading will be slow.
      * Fixed some small bugs in the interpretation of ignore patterns.
      * Fixed some problems that were preventing the Windows version from
        working correctly when click-started.
      * Fixes to treatment of file permissions under Windows, which were
        causing spurious reports of different permissions when
        synchronizing between windows and unix systems.
      * Fixed one more non-tail-recursive list processing function, which
        was causing stack overflows when synchronizing very large
        replicas.

    Changes since 1.169:
      * The text user interface now provides commands for ignoring files.
      * We found and fixed some more non-tail-recursive list processing
        functions. Some power users have reported success with very large
        replicas.
      * INCOMPATIBLE CHANGE: Files ending in .tmp are no longer ignored
        automatically. If you want to ignore such files, put an
        appropriate ignore pattern in your profile.
      * INCOMPATIBLE CHANGE: The syntax of ignore and follow patterns has
        changed. Instead of putting a line of the form

                  ignore = <regexp>
        in your profile (.unison/default.prf), you should put:

                  ignore = Regexp <regexp>
        Moreover, two other styles of pattern are also recognized:

                  ignore = Name <name>
        matches any path in which one component matches <name>, while

                  ignore = Path <path>
        matches exactly the path <path>.
        Standard ``globbing'' conventions can be used in <name> and
        <path>:
           + a ? matches any single character except /
           + a * matches any sequence of characters not including /
           + [xyz] matches any character from the set {x, y, z }
           + {a,bb,ccc} matches any one of a, bb, or ccc.
        See the user manual for some examples.

    Changes since 1.146:
      * Some users were reporting stack overflows when synchronizing huge
        directories. We found and fixed some non-tail-recursive list
        processing functions, which we hope will solve the problem. Please
        give it a try and let us know.
      * Major additions to the documentation.

    Changes since 1.142:
      * Major internal tidying and many small bugfixes.
      * Major additions to the user manual.
      * Unison can now be started with no arguments -- it will prompt
        automatically for the name of a profile file containing the roots
        to be synchronized. This makes it possible to start the graphical
        UI from a desktop icon.
      * Fixed a small bug where the text UI on NT was raising a 'no such
        signal' exception.

    Changes since 1.139:
      * The precompiled windows binary in the last release was compiled
        with an old OCaml compiler, causing propagation of permissions not
        to work (and perhaps leading to some other strange behaviors we've
        heard reports about). This has been corrected. If you're using
        precompiled binaries on Windows, please upgrade.
      * Added a -debug command line flag, which controls debugging of
        various modules. Say -debug XXX to enable debug tracing for module
        XXX, or -debug all to turn on absolutely everything.
      * Fixed a small bug where the text UI on NT was raising a 'no such
        signal' exception.

    Changes since 1.111:
      * INCOMPATIBLE CHANGE: The names and formats of the preference files
        in the .unison directory have changed. In particular:
           + the file ``prefs'' should be renamed to default.prf
           + the contents of the file ``ignore'' should be merged into
             default.prf. Each line of the form REGEXP in ignore should
             become a line of the form ignore = REGEXP in default.prf.
      * Unison now handles permission bits and symbolic links. See the
        manual for details.
      * You can now have different preference files in your .unison
        directory. If you start unison like this

              unison profilename
        (i.e. with just one ``anonymous'' command-line argument), then the
        file ~/.unison/profilename.prf will be loaded instead of
        default.prf.
      * Some improvements to terminal handling in the text user interface
      * Added a switch -killServer that terminates the remote server
        process when the unison client is shutting down, even when using
        sockets for communication. (By default, a remote server created
        using ssh/rsh is terminated automatically, while a socket server
        is left running.)
      * When started in 'socket server' mode, unison prints 'server
        started' on stderr when it is ready to accept connections. (This
        may be useful for scripts that want to tell when a socket-mode
        server has finished initalization.)
      * We now make a nightly mirror of our current internal development
        tree, in case anyone wants an up-to-the-minute version to hack
        around with.
      * Added a file CONTRIB with some suggestions for how to help us make
        Unison better.


Documentation topic news not recognized:
Type "unison -doc topics" for a list

> Hmm.  I have not notice unison changing the gid of my files.

At the moment, unison does nothing at all with uids or gids (i.e., it
doesn't work to preserve them when copying files).  This is documented
in the "Permissions" section of the manual.

> I should hope that unison would not only preserve gid, but when
> synchronizing across systems, would check to see if the gids have the
> same interpretation according to /etc/group.

This seems reasonable (as is Luke's suggestion to actually synchronize
by name instead of number).  Unfortunately, it involves more hacking...

At the moment, we (especially Jerome Vouillon and Sylvain Gommier) are
working hard on pulling together a new stable release (the most
important new feature will be the use of the rsync algorithm for
optimizing file transfers), and we're reluctant to add any
high-priority items to the todo list until this is finished.  But if
someone out there feels like hacking...  :-)

     B

"Benjamin C. Pierce" wrote:

> > That being said, there's one thing that unison does not offer (that I've
> > been able to find) that really hinder it for use in my setup:
> >
> > ability to maintain user:group ownership.
>
> I believe it would be pretty easy for us to add a simple form of
> uid/gid synchronization -- just making sure that the user and group
> ids of each file were numerically the same on both replicas.  The main
> reason we haven't done this already is that we were not sure that this
> would always be what was wanted.  (After all, the same user might have
> different uids on different systems...)  But it might be worth adding
> it as an option for people in your situation.

   Personally, I would advocate doing it by name instead of by number.  That
is, matching users and groups on the two systems by their names.  Or
providing that option anyway.

   I suppose that would be harder.  But (for me anyway) it would be more
useful.

Luke

> > That being said, there's one thing that unison does not offer (that I've
  > > been able to find) that really hinder it for use in my setup:
  > >
  > > ability to maintain user:group ownership.

Hmm.  I have not notice unison changing the gid of my files.
Gids are important to me, since I use a umask of 002, making all my
files group r/w by default.  I probably use half a dozen different
gids, but most of them are in directories that are not replicated on
my laptop (e.g., cvs repositories).

I should hope that unison would not only preserve gid, but when
synchronizing across systems, would check to see if the gids have the
same interpretation according to /etc/group.


Norman

I am using the same numerical ID on both systems.  The main purpose of
this is to have off-site backups, with the secondary purpose of allowing
a person to work away from the main office.  It is an enterprise backup;
the total amount of data being synced is now 9.5 GB and growing daily.

An option to sync IDs with unison running as root would be fantastic.
At least on my system, the security is addressed by running unison in a
vpn tunnel, so I don't have a root priveledge daemon out there.

--Yan

"Benjamin C. Pierce" wrote:
>
> > That being said, there's one thing that unison does not offer (that I've
> > been able to find) that really hinder it for use in my setup:
> >
> > ability to maintain user:group ownership.
>
> I believe it would be pretty easy for us to add a simple form of
> uid/gid synchronization -- just making sure that the user and group
> ids of each file were numerically the same on both replicas.  The main
> reason we haven't done this already is that we were not sure that this
> would always be what was wanted.  (After all, the same user might have
> different uids on different systems...)  But it might be worth adding
> it as an option for people in your situation.
>
>      Benjamin
>
> ------------------------------------------------------------------------
> Best friends, most artistic, class clown Find 'em here:
> http://click.egroups.com/1/4054/1/_/844773/_/959178506/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe@onelist.com

--

Think different
	 ride a recumbent
		 use Linux.

> That being said, there's one thing that unison does not offer (that I've
> been able to find) that really hinder it for use in my setup:
>
> ability to maintain user:group ownership.

I believe it would be pretty easy for us to add a simple form of
uid/gid synchronization -- just making sure that the user and group
ids of each file were numerically the same on both replicas.  The main
reason we haven't done this already is that we were not sure that this
would always be what was wanted.  (After all, the same user might have
different uids on different systems...)  But it might be worth adding
it as an option for people in your situation.

      Benjamin

I've just started using unison, and I must say it worked "right out of
the box".  A piece of cake.  I'd been struggling with rsync for a while
and unison was a welcome change.

That being said, there's one thing that unison does not offer (that I've
been able to find) that really hinder it for use in my setup:

ability to maintain user:group ownership.

I have gotten around this by forcing unison to run as one of the
authorized users, but it only works on a small part of my network.  I
have two major groups, and neither group is allowed read/write access to
the other's files.  unison destroys this ownership and permisions, so I
am back to using rsync for the bulk of my transfers.  There are
sub-areas of the network where only priveledged users from each group
are allowed access; I can't run a server for each of these.

Even calling it is a hack:  since unison must run as a normal user, I
can't use a priviledged port for it to run on.  Here's what I'm using
(it runs from the startup scripts):

su yan  -c "unison -socket 1874 &"

I'd love to have a cleaner workaround.

--Yan

--

Think different
	 ride a recumbent
		 use Linux.

Here's an update.

   I've switched to running unison on the NFS server machine, instead of the
NFS client, and now unison is working perfectly.  I have to assume that the bad
press that the Linux NFS server implementation receives is justified.  On the
far end I am still running unison on an NFS client, but the server there is
FreeBSD not Linux.

   Sorry for the wasted bandwidth.  And thanks for the tool.

Luke


Luke Blanshard wrote:

> Jerome Vouillon wrote:
>
> > On Fri, Apr 28, 2000 at 08:19:48AM -0700, Luke Blanshard wrote:
> > >  ...  I'm seeing errors
> > > like "Uncaught exception Remote.GrabEOF" consistently...
> >
> > This error means that the server is crashing for some reason.
> > When does it happen: immediately after you start unison, during the
> > check for updates or during the synchronisation?
>
> During the check for updates.
>
> > Also, could you send us what gets printed when you run unison with the
> > '-debug all' flag.
>
> Well, I got 19 megs of output on the client and 22 on the server.  Also, it
> died on a different error this time, an undifferentiated write error while
> writing the client's archive file.  Just FYI, there's plenty of room on both
> directories, and in my home directory too.
>
> Here is the tail of the server's output:
>
> [server:  update] updatePathInArchive NoArchive /raid0/share
> [mozilla/xpcom/proxy/tests/CVS/Entries] []
> [server:  update] updateArchiveLocal
> /raid0/share/mozilla/xpfe/xpviewer/src/CVS/Entries
> [server:  update] updatePathInArchive ArchiveDir /raid0/share []
> [mozilla/xpfe/xpviewer/src/CVS/Entries]
> [server:  update] updatePathInArchive ArchiveDir /raid0/share [mozilla]
> [xpfe/xpviewer/src/CVS/Entries]
> [server:  update] updatePathInArchive ArchiveDir /raid0/share [mozilla/xpfe]
> [xpviewer/src/CVS/Entries]
> [server:  update] updatePathInArchive ArchiveDir /raid0/share
> [mozilla/xpfe/xpviewer] [src/CVS/Entries]
> [server:  update] updatePathInArchive ArchiveDir /raid0/share
> [mozilla/xpfe/xpviewer/src] [CVS/Entries]
> [server:  update] updatePathInArchive ArchiveDir /raid0/share
> [mozilla/xpfe/xpviewer/src/CVS] [Entries]
> [server:  update] updatePathInArchive NoArchive /raid0/share
> [mozilla/xpfe/xpviewer/src/CVS/Entries] []
> [server:  update] Saving archive in
> /home/luke/.unison/sc1a1f7d865ef48de072c514eada409a02
>
> And here is the tail of the client:
>
> [update] updatePathInArchive ArchiveDir /quiq/share
> [mozilla/xpcom/proxy/tests] [CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share
> [mozilla/xpcom/proxy/tests/CVS] [Entries]
> [update] updatePathInArchive NoArchive /quiq/share
> [mozilla/xpcom/proxy/tests/CVS/Entries] []
> [update] updateArchiveLocal
> /quiq/share/mozilla/xpfe/xpviewer/src/CVS/Entries
> [update] updatePathInArchive ArchiveDir /quiq/share []
> [mozilla/xpfe/xpviewer/src/CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share [mozilla]
> [xpfe/xpviewer/src/CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share [mozilla/xpfe]
> [xpviewer/src/CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share [mozilla/xpfe/xpviewer]
> [src/CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share
> [mozilla/xpfe/xpviewer/src] [CVS/Entries]
> [update] updatePathInArchive ArchiveDir /quiq/share
> [mozilla/xpfe/xpviewer/src/CVS] [Entries]
> [update] updatePathInArchive NoArchive /quiq/share
> [mozilla/xpfe/xpviewer/src/CVS/Entries] []
> [update] Updating archives
> [update] Saving archive in
> /export/home/luke/.unison/sc14d51f00320587f9deb95e3c5cd90e7c
> [update] Copying archive
> /export/home/luke/.unison/tm14d51f00320587f9deb95e3c5cd90e7c to
> /export/home/luke/.unison/ar14d51f00320587f9deb95e3c5cd90e7c
> [exn] Converting a Unix error to Transient:
> Error in readWrite:
> Input/output error [write()]
> [exn] Converting a Transient error to Fatal:
> Error in readWrite:
> Input/output error [write()]
>
> > If you are not using the latest stable release (1.231), you should
> > definitively upgrade. But I don't think it will solve your problem.
>
> That's the version I'm using.
>
> Thanks for replying, and let me know if you need more data!
>
> Luke
>
> ------------------------------------------------------------------------
> Accurate impartial advice on everything from laptops to table saws.
> http://click.egroups.com/1/3020/0/_/844773/_/956960704/
> ------------------------------------------------------------------------
>
> To unsubscribe from this group, send an email to:
> unison-users-unsubscribe@onelist.com

> The marshaling format has not changed since at least OCaml 1.06. So,
> there should be no compatibility problem between the different ocaml
> compilers.
>
> I suspect you got this error because prcs does not update the version
> number when you merge some changes. So, you ran two versions of unison
> that was actually incompatible. (I made some incompatible changes just
> before you had this problem.)

You're right -- I was misremembering.

        B

On Fri, Apr 28, 2000 at 06:48:09PM -0400, Benjamin C. Pierce wrote:
> I had this problem a couple of days ago.  Did you perhaps compile
> unison with different version of the ocaml compiler on the two
> machines?

The marshaling format has not changed since at least OCaml 1.06. So,
there should be no compatibility problem between the different ocaml
compilers.

I suspect you got this error because prcs does not update the version
number when you merge some changes. So, you ran two versions of unison
that was actually incompatible. (I made some incompatible changes just
before you had this problem.)

-- Jérôme

"Benjamin C. Pierce" wrote:

> I had this problem a couple of days ago.  Did you perhaps compile
> unison with different version of the ocaml compiler on the two
> machines?

Nope, I'm running one of the precompiled versions, the same on both
machines.  Now, one of them is running Linux 2.2.14 and the other is
2.2.13, but that's the only difference I know about.  And I have a hard
time believing that has anything to do with it.

Luke

(Not sure if this got posted before...)

I had this problem a couple of days ago.  Did you perhaps compile
unison with different version of the ocaml compiler on the two
machines?

           B

Jerome Vouillon wrote:

> On Fri, Apr 28, 2000 at 08:19:48AM -0700, Luke Blanshard wrote:
> >  ...  I'm seeing errors
> > like "Uncaught exception Remote.GrabEOF" consistently...
>
> This error means that the server is crashing for some reason.
> When does it happen: immediately after you start unison, during the
> check for updates or during the synchronisation?

During the check for updates.

> Also, could you send us what gets printed when you run unison with the
> '-debug all' flag.

Well, I got 19 megs of output on the client and 22 on the server.  Also, it
died on a different error this time, an undifferentiated write error while
writing the client's archive file.  Just FYI, there's plenty of room on both
directories, and in my home directory too.

Here is the tail of the server's output:

[server:  update] updatePathInArchive NoArchive /raid0/share
[mozilla/xpcom/proxy/tests/CVS/Entries] []
[server:  update] updateArchiveLocal
/raid0/share/mozilla/xpfe/xpviewer/src/CVS/Entries
[server:  update] updatePathInArchive ArchiveDir /raid0/share []
[mozilla/xpfe/xpviewer/src/CVS/Entries]
[server:  update] updatePathInArchive ArchiveDir /raid0/share [mozilla]
[xpfe/xpviewer/src/CVS/Entries]
[server:  update] updatePathInArchive ArchiveDir /raid0/share [mozilla/xpfe]
[xpviewer/src/CVS/Entries]
[server:  update] updatePathInArchive ArchiveDir /raid0/share
[mozilla/xpfe/xpviewer] [src/CVS/Entries]
[server:  update] updatePathInArchive ArchiveDir /raid0/share
[mozilla/xpfe/xpviewer/src] [CVS/Entries]
[server:  update] updatePathInArchive ArchiveDir /raid0/share
[mozilla/xpfe/xpviewer/src/CVS] [Entries]
[server:  update] updatePathInArchive NoArchive /raid0/share
[mozilla/xpfe/xpviewer/src/CVS/Entries] []
[server:  update] Saving archive in
/home/luke/.unison/sc1a1f7d865ef48de072c514eada409a02

And here is the tail of the client:

[update] updatePathInArchive ArchiveDir /quiq/share
[mozilla/xpcom/proxy/tests] [CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share
[mozilla/xpcom/proxy/tests/CVS] [Entries]
[update] updatePathInArchive NoArchive /quiq/share
[mozilla/xpcom/proxy/tests/CVS/Entries] []
[update] updateArchiveLocal
/quiq/share/mozilla/xpfe/xpviewer/src/CVS/Entries
[update] updatePathInArchive ArchiveDir /quiq/share []
[mozilla/xpfe/xpviewer/src/CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share [mozilla]
[xpfe/xpviewer/src/CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share [mozilla/xpfe]
[xpviewer/src/CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share [mozilla/xpfe/xpviewer]
[src/CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share
[mozilla/xpfe/xpviewer/src] [CVS/Entries]
[update] updatePathInArchive ArchiveDir /quiq/share
[mozilla/xpfe/xpviewer/src/CVS] [Entries]
[update] updatePathInArchive NoArchive /quiq/share
[mozilla/xpfe/xpviewer/src/CVS/Entries] []
[update] Updating archives
[update] Saving archive in
/export/home/luke/.unison/sc14d51f00320587f9deb95e3c5cd90e7c
[update] Copying archive
/export/home/luke/.unison/tm14d51f00320587f9deb95e3c5cd90e7c to
/export/home/luke/.unison/ar14d51f00320587f9deb95e3c5cd90e7c
[exn] Converting a Unix error to Transient:
Error in readWrite:
Input/output error [write()]
[exn] Converting a Transient error to Fatal:
Error in readWrite:
Input/output error [write()]

> If you are not using the latest stable release (1.231), you should
> definitively upgrade. But I don't think it will solve your problem.

That's the version I'm using.

Thanks for replying, and let me know if you need more data!

Luke

On Fri, Apr 28, 2000 at 08:19:48AM -0700, Luke Blanshard wrote:
>   I've been using unison for a few weeks, trying to keep a couple of
> geographically dispersed directories in sync.  For a while it worked
> pretty well, but now it dies every time I run it.  I'm seeing errors
> like "Uncaught exception Remote.GrabEOF" consistently.  I tried blowing
> away the archive files on both sides of the link but that didn't solve
> the problem, just changed the error messages.  Before this I was seeing
> messages about getting unexpected kinds of results---unfortunately,
> I didn't save the text of those messages.

This error means that the server is crashing for some reason.
When does it happen: immediately after you start unison, during the
check for updates or during the synchronisation?
Also, could you send us what gets printed when you run unison with the
'-debug all' flag.

>   These directories are big.  The files add up to over a gig in size
> spread over more than 80,000 files.
>
>   Does this ring a bell?  Should I try the latest snapshot instead?

If you are not using the latest stable release (1.231), you should
definitively upgrade. But I don't think it will solve your problem.

> Or am I pushing this thing beyond its capacity?

No, Unison should be able to handle this without problem.

-- Jérôme

I've been using unison for a few weeks, trying to keep a couple of
geographically dispersed directories in sync.  For a while it worked
pretty well, but now it dies every time I run it.  I'm seeing errors
like "Uncaught exception Remote.GrabEOF" consistently.  I tried blowing
away the archive files on both sides of the link but that didn't solve
the problem, just changed the error messages.  Before this I was seeing
messages about getting unexpected kinds of results---unfortunately,
I didn't save the text of those messages.

   These directories are big.  The files add up to over a gig in size
spread over more than 80,000 files.

   Does this ring a bell?  Should I try the latest snapshot instead?  Or
am I pushing this thing beyond its capacity?

Thanks,
Luke


P.S. The link to the mailing list from the download page is broken now
that onelist has been absorbed by egroups...