From ben at opendarwin.org  Sun Sep 18 10:16:59 2005
From: ben at opendarwin.org (Ben Willmore)
Date: Sun, 18 Sep 2005 07:16:59 -0700
Subject: [Unison-hackers] mac patches
Message-ID: <bd9b873a050918071682b0bd8@mail.gmail.com>

Hi,

Here are 3 patches against current SVN unison that fix the following
problems with the mac UI.

1. tiger-ssh-prompt-patch.20050916
To work with a variety of systems, terminal.ml needs to recognize
_both_ 'Password:' and 'Password: '.  This patch provides an
appropriate regex.  [This was wrongly fixed between 2.13.16 and
current SVN.]

2. uimac-passphrase-prompt-nobin.patch.20050916
Extends password UI so it will request an ssh passphrase if necessary,
allowing use of passphrase-protected ssh keys.  Note this only patches
the ascii files -- for it to work, you need to also alter the .nib
file: Make a new outlet for MyController, called passwordPrompt, of
type NSTextField.  Connect this to the text 'Please enter your
password' in the Password window.

3. uimac-password-sheet.patch.20050916
Fixes bug where providing a profile name on the command line confuses
the password window (it is detached from the main window), and leads
to a crash on a second sync.

One last thing -- the UI opens halfway off-screen for me in the
current SVN version.

Cheers

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tiger-ssh-prompt-patch.20050916
Type: application/octet-stream
Size: 408 bytes
Desc: not available
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20050918/8e80ee7f/tiger-ssh-prompt-patch.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uimac-passphrase-prompt-nobin.patch.20050916
Type: application/octet-stream
Size: 2910 bytes
Desc: not available
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20050918/8e80ee7f/uimac-passphrase-prompt-nobin.patch.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uimac-password-sheet.patch.20050916
Type: application/octet-stream
Size: 521 bytes
Desc: not available
Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20050918/8e80ee7f/uimac-password-sheet.patch.obj

From ben at opendarwin.org  Sun Sep 18 16:17:26 2005
From: ben at opendarwin.org (Ben Willmore)
Date: Sun, 18 Sep 2005 13:17:26 -0700
Subject: [Unison-hackers] mac patches
In-Reply-To: <bd9b873a050918071682b0bd8@mail.gmail.com>
References: <bd9b873a050918071682b0bd8@mail.gmail.com>
Message-ID: <bd9b873a050918131710b94a05@mail.gmail.com>

On 9/18/05, Ben Willmore <ben at opendarwin.org> wrote:
> ...

Looks like the patches got scrubbed. see:
http://socrates.berkeley.edu/~benwill/unison/

Ben

From ben at opendarwin.org  Mon Sep 19 10:11:41 2005
From: ben at opendarwin.org (Ben Willmore)
Date: Mon, 19 Sep 2005 07:11:41 -0700
Subject: [Unison-hackers] osxsupport.c
Message-ID: <bd9b873a050919071156356707@mail.gmail.com>

As unison maintainer in Fink (mac os x), I inherited the included
patch against 2.10.2.  I wrongly assumed it had been incorporated into
newer versions.

Can anyone comment on the wisdom of including this?

Thanks,

Ben


diff -u -ruN unison.orig/unison-2.10.2/osxsupport.c
unison/unison-2.10.2/osxsupport.c
--- unison.orig/unison-2.10.2/osxsupport.c      2005-08-23
09:00:53.000000000 -0700
+++ unison/unison-2.10.2/osxsupport.c   2005-08-23 09:01:50.000000000 -0700
@@ -6,6 +6,8 @@
 #include <caml/alloc.h>
 #include <caml/memory.h>
 #ifdef __APPLE__
+#include <sys/types.h>
+#include <sys/stat.h>
 #include <sys/attr.h>
 #include <unistd.h>
 #include <stdio.h>
@@ -115,6 +117,20 @@
   retcode = setattrlist(String_val (path), &attrList, attrBuf.finderInfo,
                         sizeof attrBuf.finderInfo, options);
 
+  if (retcode == -1 && errno == EACCES) {
+    /* Unlike with normal Unix attributes, we cannot set OS X attributes 
+       if file is read-only.  Try making it writable temporarily. */
+    struct stat st;
+    int r = stat(String_val(path), &st);
+    if (r == -1) uerror("setattrlist", path);
+    r = chmod(String_val(path), st.st_mode | S_IWUSR);
+    if (r == -1) uerror("setattrlist", path);
+    /* Try again */
+    retcode = setattrlist(String_val (path), &attrList, attrBuf.finderInfo,
+                          sizeof attrBuf.finderInfo, options);
+    /* Whether or not that worked, we should try to set the mode back. */
+    chmod(String_val(path), st.st_mode);
+  }
   if (retcode == -1) uerror("setattrlist", path);
 
   CAMLreturn (Val_unit);

From bcpierce at cis.upenn.edu  Mon Sep 19 10:16:57 2005
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Mon, 19 Sep 2005 10:16:57 -0400
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <bd9b873a050919071156356707@mail.gmail.com>
References: <bd9b873a050919071156356707@mail.gmail.com>
Message-ID: <1924BD4C-34DC-491F-81D6-6234A946768A@cis.upenn.edu>

I won't comment on the code now because I didn't write it and don't  
have a good feeling for the circumstances under which a crash could  
leave a read-only file in a writeable state, but a general comment  
would be that having different flavors of Unison behave differently  
on the very same OS is sure to be a bad thing: the patch should  
definitely either be thrown away or get incorporated into the main  
sources.

    - B


On Sep 19, 2005, at 10:11 AM, Ben Willmore wrote:

> As unison maintainer in Fink (mac os x), I inherited the included
> patch against 2.10.2.  I wrongly assumed it had been incorporated into
> newer versions.
>
> Can anyone comment on the wisdom of including this?
>
> Thanks,
>
> Ben
>
>
> diff -u -ruN unison.orig/unison-2.10.2/osxsupport.c
> unison/unison-2.10.2/osxsupport.c
> --- unison.orig/unison-2.10.2/osxsupport.c      2005-08-23
> 09:00:53.000000000 -0700
> +++ unison/unison-2.10.2/osxsupport.c   2005-08-23  
> 09:01:50.000000000 -0700
> @@ -6,6 +6,8 @@
>  #include <caml/alloc.h>
>  #include <caml/memory.h>
>  #ifdef __APPLE__
> +#include <sys/types.h>
> +#include <sys/stat.h>
>  #include <sys/attr.h>
>  #include <unistd.h>
>  #include <stdio.h>
> @@ -115,6 +117,20 @@
>    retcode = setattrlist(String_val (path), &attrList,  
> attrBuf.finderInfo,
>                          sizeof attrBuf.finderInfo, options);
>
> +  if (retcode == -1 && errno == EACCES) {
> +    /* Unlike with normal Unix attributes, we cannot set OS X  
> attributes
> +       if file is read-only.  Try making it writable temporarily. */
> +    struct stat st;
> +    int r = stat(String_val(path), &st);
> +    if (r == -1) uerror("setattrlist", path);
> +    r = chmod(String_val(path), st.st_mode | S_IWUSR);
> +    if (r == -1) uerror("setattrlist", path);
> +    /* Try again */
> +    retcode = setattrlist(String_val (path), &attrList,  
> attrBuf.finderInfo,
> +                          sizeof attrBuf.finderInfo, options);
> +    /* Whether or not that worked, we should try to set the mode  
> back. */
> +    chmod(String_val(path), st.st_mode);
> +  }
>    if (retcode == -1) uerror("setattrlist", path);
>
>    CAMLreturn (Val_unit);
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>


From ben at opendarwin.org  Mon Sep 19 16:26:44 2005
From: ben at opendarwin.org (Ben Willmore)
Date: Mon, 19 Sep 2005 13:26:44 -0700
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <mailman.3035.1127161530.29807.unison-hackers@lists.seas.upenn.edu>
References: <mailman.3035.1127161530.29807.unison-hackers@lists.seas.upenn.edu>
Message-ID: <bd9b873a05091913262619bff7@mail.gmail.com>

 On 9/19/05, Benjamin Pierce <bcpierce at cis.upenn.edu> wrote:
 
 > but a general comment
 > would be that having different flavors of Unison behave differently
 > on the very same OS is sure to be a bad thing: the patch should
 > definitely either be thrown away or get incorporated into the main
 > sources.
 
 I totally agree, and I'm happy to remove the patch from fink if you or
 the consensus here think it's detrimental.  All the other fink patches
 are ones that have been incorporated in newer versions of the main
 Unison tree (the ones from Andrew Schulman's page, plus the
 mac-specific fixes I sent to this list a few weeks ago).  The
 oxsupport.c patch is the only one that hasn't -- hence my original
 question.
 
 What's the best way to come to a decision?  I know I'm not qualified
 to make it :-)
 
 Ben

From bcpierce at cis.upenn.edu  Mon Sep 19 21:23:43 2005
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Mon, 19 Sep 2005 21:23:43 -0400
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <bd9b873a05091913262619bff7@mail.gmail.com>
References: <mailman.3035.1127161530.29807.unison-hackers@lists.seas.upenn.edu>
	<bd9b873a05091913262619bff7@mail.gmail.com>
Message-ID: <A87EE8E5-3FBB-4B1A-AA56-AF7EEFAAEA1E@cis.upenn.edu>

I'm tempted to deal with this issue by adding a switch controlling  
the behavior (probably defaulting it to true), carefully documenting  
what the switch does, and letting people choose for themselves.  It's  
a tradeoff between risk and convenience, and I suspect there's really  
no right answer.

Regards,

    - Benjamin


On Sep 19, 2005, at 4:26 PM, Ben Willmore wrote:

>  On 9/19/05, Benjamin Pierce <bcpierce at cis.upenn.edu> wrote:
>
>
>> but a general comment
>> would be that having different flavors of Unison behave differently
>> on the very same OS is sure to be a bad thing: the patch should
>> definitely either be thrown away or get incorporated into the main
>> sources.
>>
>
>  I totally agree, and I'm happy to remove the patch from fink if  
> you or
>  the consensus here think it's detrimental.  All the other fink  
> patches
>  are ones that have been incorporated in newer versions of the main
>  Unison tree (the ones from Andrew Schulman's page, plus the
>  mac-specific fixes I sent to this list a few weeks ago).  The
>  oxsupport.c patch is the only one that hasn't -- hence my original
>  question.
>
>  What's the best way to come to a decision?  I know I'm not qualified
>  to make it :-)
>
>  Ben
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>


From Jerome.Vouillon at pps.jussieu.fr  Tue Sep 20 12:49:22 2005
From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon)
Date: Tue, 20 Sep 2005 18:49:22 +0200
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <bd9b873a050919071156356707@mail.gmail.com>
References: <bd9b873a050919071156356707@mail.gmail.com>
Message-ID: <20050920164922.GC3181@strontium.pps.jussieu.fr>

On Mon, Sep 19, 2005 at 07:11:41AM -0700, Ben Willmore wrote:
> As unison maintainer in Fink (mac os x), I inherited the included
> patch against 2.10.2.  I wrongly assumed it had been incorporated into
> newer versions.
> 
> Can anyone comment on the wisdom of including this?

The permissions used to be set before the OS X file attributes.
Thus, the synchronization of a read-only file with some attributes
systematically failed.  Now, the order is reversed and the
synchronization is unlikely to fail (this may happen only if the
attributes of a read-only files are changed but its contents remain
unchanged).  So the patch is not as important as it used to be.

I'm not sure whether this is an argument to drop it (the
synchronization is unlikely to fail) or to apply it (the patch is
unlikely to do any harm)...

-- Jerome

From ben at opendarwin.org  Thu Sep 22 01:10:19 2005
From: ben at opendarwin.org (Ben Willmore)
Date: Wed, 21 Sep 2005 22:10:19 -0700
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <20050920164922.GC3181@strontium.pps.jussieu.fr>
References: <bd9b873a050919071156356707@mail.gmail.com>
	<20050920164922.GC3181@strontium.pps.jussieu.fr>
Message-ID: <bd9b873a05092122105b24d7f0@mail.gmail.com>

On 9/20/05, Jerome Vouillon <Jerome.Vouillon at pps.jussieu.fr> wrote:
> On Mon, Sep 19, 2005 at 07:11:41AM -0700, Ben Willmore wrote:
> > As unison maintainer in Fink (mac os x), I inherited the included
> > patch against 2.10.2.  I wrongly assumed it had been incorporated into
> > newer versions.
<snip>
> synchronization is unlikely to fail (this may happen only if the
> attributes of a read-only files are changed but its contents remain
> unchanged).  So the patch is not as important as it used to be.
<snip>
> I'm not sure whether this is an argument to drop it (the
> synchronization is unlikely to fail) or to apply it (the patch is
> unlikely to do any harm)...

This sounds like a clear argument in favour of the patch to me: if it
fixes a real problem (systematic  failure to synchronise
attribute-changes on read-only files) and is unlikely to do any harm,
it seems worth having.

Am I right in understanding that the risk is that a read-only file may
be left owner-writable in the event of a crash?  Can the same occur if
a crash happens between the setting of the attributes and the setting
of the permisssions? If so, it seems the negative impact of the patch
is minimal.

Ben

Ben

From bcpierce at cis.upenn.edu  Sat Sep 24 13:11:01 2005
From: bcpierce at cis.upenn.edu (Benjamin Pierce)
Date: Sat, 24 Sep 2005 19:11:01 +0200
Subject: [Unison-hackers] osxsupport.c
In-Reply-To: <bd9b873a05092122105b24d7f0@mail.gmail.com>
References: <bd9b873a050919071156356707@mail.gmail.com>
	<20050920164922.GC3181@strontium.pps.jussieu.fr>
	<bd9b873a05092122105b24d7f0@mail.gmail.com>
Message-ID: <10CBD918-91D3-4B82-8593-2FF718EA2FE8@cis.upenn.edu>

OK, keeping the patch seems reasonable.  I've incorporated it in the  
development sources.  You can either apply it or not (I don't think  
it matters much, so maybe better not, for the sake of consistency) in  
the current Fink version.

Regards,

     - Benjamin


On Sep 22, 2005, at 7:10 AM, Ben Willmore wrote:

> On 9/20/05, Jerome Vouillon <Jerome.Vouillon at pps.jussieu.fr> wrote:
>
>> On Mon, Sep 19, 2005 at 07:11:41AM -0700, Ben Willmore wrote:
>>
>>> As unison maintainer in Fink (mac os x), I inherited the included
>>> patch against 2.10.2.  I wrongly assumed it had been incorporated  
>>> into
>>> newer versions.
>>>
> <snip>
>
>> synchronization is unlikely to fail (this may happen only if the
>> attributes of a read-only files are changed but its contents remain
>> unchanged).  So the patch is not as important as it used to be.
>>
> <snip>
>
>> I'm not sure whether this is an argument to drop it (the
>> synchronization is unlikely to fail) or to apply it (the patch is
>> unlikely to do any harm)...
>>
>
> This sounds like a clear argument in favour of the patch to me: if it
> fixes a real problem (systematic  failure to synchronise
> attribute-changes on read-only files) and is unlikely to do any harm,
> it seems worth having.
>
> Am I right in understanding that the risk is that a read-only file may
> be left owner-writable in the event of a crash?  Can the same occur if
> a crash happens between the setting of the attributes and the setting
> of the permisssions? If so, it seems the negative impact of the patch
> is minimal.
>
> Ben
>
> Ben
> _______________________________________________
> Unison-hackers mailing list
> Unison-hackers at lists.seas.upenn.edu
> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers
>


From michael.parsons at ucdmc.ucdavis.edu  Sat Sep 24 21:03:32 2005
From: michael.parsons at ucdmc.ucdavis.edu (Michael Parsons)
Date: Sat, 24 Sep 2005 18:03:32 -0700
Subject: [Unison-hackers] Michael Parsons/IS/HS/UCD is out of the office.
Message-ID: <OF4B1838C6.25220900-ON88257087.0005D117-88257087.0005D117@ucdmc.ucdavis.edu>


I will be out of the office starting  09/19/2005 and will not return until
10/10/2005.



From bcpierce at cis.upenn.edu  Mon Sep 26 15:46:24 2005
From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu)
Date: Mon, 26 Sep 2005 15:46:24 -0400
Subject: [Unison-hackers] [unison-svn] r105 - trunk/src
Message-ID: <200509261946.j8QJkOF3025266@canfield.cis.upenn.edu>

Author: bcpierce
Date: 2005-09-26 15:46:19 -0400 (Mon, 26 Sep 2005)
New Revision: 105

Modified:
   trunk/src/RECENTNEWS
   trunk/src/mkProjectInfo.ml
   trunk/src/osxsupport.c
Log:
* Incorporated old patch to set read-only file to R/W on OSX before
  attempting to change other attributes, per discussion on
  unison-hackers list.  



From jdunn14 at hotpop.com  Mon Sep 26 23:07:18 2005
From: jdunn14 at hotpop.com (Joseph Dunn)
Date: Mon, 26 Sep 2005 21:07:18 -0600
Subject: [Unison-hackers] unison 2.13.16 output patch
Message-ID: <20050926210718.690cfab6@localhost.localdomain>

Alright, another attempt at sending this (by the way,
http://www.cis.upenn.edu/~bcpierce/unison/status.html incorrectly
refers to unison-hackers at yahoogroups.com)

I was using the textui and discovered that the terse option drops some
necessary newlines in the output.  For example, before my patch output
looks like:
[jdunn at porkrind ~]$ ./unison-2.13.16-linux-text starcraft -batch -terse -path .mozilla
Contacting server...

local          starcraft...
changed  <-?-> changed    .mozilla/default/u8gzcu6e.slt/XUL.mfasl  changed  <-?-> changed    .mozilla/default/u8gzcu6e.slt/cookies.txt  changed  <-?-> changed   .mozilla/default/u8gzcu6e.slt/history.dat  No updates to propagate

After the patch:
[jdunn at porkrind ~]$ unison starcraft -batch -terse -path .mozilla
Contacting server...

local          starcraft...
changed  <-?-> changed    .mozilla/default/u8gzcu6e.slt/XUL.mfasl
changed  <-?-> changed    .mozilla/default/u8gzcu6e.slt/cookies.txt
changed  <-?-> changed    .mozilla/default/u8gzcu6e.slt/history.dat
No updates to propagate

The patch is as follows:
-----------------------------------------------------------------
diff -Naur unison-2.13.16.new/uitext.ml unison-2.13.16/uitext.ml
--- unison-2.13.16.new/uitext.ml	2005-06-02 09:59:21.000000000 -0600
+++ unison-2.13.16/uitext.ml	2005-09-16 14:35:27.000000000 -0600
@@ -222,8 +222,11 @@
                   "from "^host1^" to "^host2,
                   "from "^host2^" to "^host1
               in
-              if Prefs.read Globals.batch && not (Prefs.read Trace.terse) then
-                (display "\n"; displayDetails ri);
+              if Prefs.read Globals.batch then begin
+                display "\n";
+                if not (Prefs.read Trace.terse) then
+                  displayDetails ri
+              end;
               selectAction
                 (if Prefs.read Globals.batch then Some " " else None)
                 [((if !dir=Conflict && not (Prefs.read Globals.batch)
-----------------------------------------------------------------
Does this make sense?

On a different note, I have a patch that seems necessary to make
STATIC=true work on my machine:
-----------------------------------------------------------------
diff -Naur unison-2.13.16/Makefile.OCaml unison-2.13.16.new/Makefile.OCaml
--- unison-2.13.16/Makefile.OCaml       2005-06-27 11:38:25.000000000 -0600
+++ unison-2.13.16.new/Makefile.OCaml   2005-09-16 14:19:54.000000000 -0600
@@ -330,7 +330,7 @@

 $(NAME)$(EXEC_EXT): $(CAMLOBJS) $(COBJS)
        @echo Linking $@
-       $(CAMLC) -verbose $(CAMLFLAGS) -o $@ $(CFLAGS) $(CAMLLIBS) $(CLIBS) $^
+       $(CAMLC) -verbose $(CAMLFLAGS) -o $@ $(CFLAGS) $(CAMLLIBS) $^ $(CLIBS) $(STATICLIBS)

 # Unfortunately -output-obj does not put .o files into the output, only .cmx
 # files, so we have to use $(LD) to take care of COBJS.
-----------------------------------------------------------------

-Joseph Dunn


From dworley at pingtel.com  Fri Sep 30 17:33:52 2005
From: dworley at pingtel.com (Dale R. Worley)
Date: Fri, 30 Sep 2005 17:33:52 -0400
Subject: [Unison-hackers] Need fix for chmod problem
Message-ID: <1128116032.25455.26.camel@cdhcp139.pingtel.com>

I've gotten stuck in a situation where I really need to suppress any
attempt by Unison to change the permissions of files.

(One of the directories is on an SMB share mounted on a Linux system.
chmod calls on that filesystem fail, and there is no "quiet" option to
prevent them from returning errors.)

I don't know ML, but Unison is really clean code, so I think I know what
needs to be done.  In props.ml at lines 166 et seq. is the function:

let set fspath path kind (fp, mask) =
  if mask <> 0 || kind <> `Update then
    Util.convertUnixErrorsToTransient
    "setting permissions"
      (fun () ->
        let abspath = Fspath.concatToString fspath path in
        debug
          (fun() ->
            Util.msg "Setting permissions for %s to %s (%s)\n"
              abspath (toString (fileperm2perm fp))
              (Printf.sprintf "%o/%o" fp mask));
        Unix.chmod abspath fp)

I think that the second line is incorrect, in that if mask is 0, but the
kind of operation is not Update (and specifically, if it is the creation
of a file), the code will still attempt to chmod the file.  Instead,
that 'if' clause should be:

  if mask <> 0 then

Do you developers agree with me?

Thanks, as this is a real problem here,

Dale



From dworley at pingtel.com  Fri Sep 30 17:48:26 2005
From: dworley at pingtel.com (Dale R. Worley)
Date: Fri, 30 Sep 2005 17:48:26 -0400
Subject: [Unison-hackers] Error message "Destination updated during
	synchronization" does	not give file name
Message-ID: <1128116906.25455.30.camel@cdhcp139.pingtel.com>

I recently received the error message "Destination updated during
synchronization", and noticed that it does not tell the name of the file
in question.  I think this message should include the name of the file
that had the problem.  As far as I can tell, the name of the file in
question is available through localPath and/or pathInArchive.  Could
somebody make the requisite fix?

Thanks,

Dale