From Jerome.Vouillon at pps.jussieu.fr Sat Oct 1 10:43:34 2005 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Sat, 1 Oct 2005 16:43:34 +0200 Subject: [Unison-hackers] [unison-users] Address family not supported by protocol [socket()] In-Reply-To: <20051001143016.30704.qmail@web52903.mail.yahoo.com> References: <20050930202739.GA19104@strontium.pps.jussieu.fr> <20051001143016.30704.qmail@web52903.mail.yahoo.com> Message-ID: <20051001144334.GA23848@strontium.pps.jussieu.fr> Hi Chuck, On Sat, Oct 01, 2005 at 10:30:16AM -0400, Chuck Farley wrote: > I'm using unison-2.17.1-linux-text. Which I only just > realized is a BETA. Damn never noticed that. Will > try the latest stable. [...] > strace unison -socket 9876 [...] > socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 So, this is due to the IPV6 support code which was recently added to Unison. The latest stable version should not have this problem. Thanks for the bug report! -- Jerome From samuel.thibault at ens-lyon.org Sat Oct 1 11:03:54 2005 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sat, 1 Oct 2005 17:03:54 +0200 Subject: [Unison-hackers] [unison-users] Address family not supported by protocol [socket()] In-Reply-To: <20051001144334.GA23848@strontium.pps.jussieu.fr> References: <20050930202739.GA19104@strontium.pps.jussieu.fr> <20051001143016.30704.qmail@web52903.mail.yahoo.com> <20051001144334.GA23848@strontium.pps.jussieu.fr> Message-ID: <20051001150354.GY5321@bouh.residence.ens-lyon.fr> Hi, Jerome Vouillon, le Sat 01 Oct 2005 16:43:34 +0200, a ?crit : > Hi Chuck, > > On Sat, Oct 01, 2005 at 10:30:16AM -0400, Chuck Farley wrote: > > I'm using unison-2.17.1-linux-text. Which I only just > > realized is a BETA. Damn never noticed that. Will > > try the latest stable. > [...] > > strace unison -socket 9876 > [...] > > socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 > > So, this is due to the IPV6 support code which was recently added to > Unison. The latest stable version should not have this problem. Indeed. I'm afraid I missed the whole bug report, but I guess Chuck complains about a spurious warning to be emitted. That warning is a bit useless indeed, here is a patch: --- remote-orig.ml 2005-10-01 16:55:40.000000000 +0200 +++ remote.ml 2005-10-01 16:59:28.000000000 +0200 @@ -824,9 +824,10 @@ Unix.connect socket ai.Unix.ai_addr; initConnection socket socket with - Unix.Unix_error (_, _, reason) -> - (Util.warn - (Printf.sprintf + Unix.Unix_error (error, _, reason) -> + (if error != Unix.EAFNOSUPPORT then + Util.warn + (Printf.sprintf "Can't connect to server (%s:%s): %s" host port reason); loop r) end @@ -1137,11 +1138,12 @@ Unix.listen socket 1; socket with - Unix.Unix_error (_, _, reason) -> - (Util.warn - (Printf.sprintf - "Can't bind to host (%s:%s): %s" ai.Unix.ai_canonname port - reason); + Unix.Unix_error (error, _, reason) -> + (if error != Unix.EAFNOSUPPORT then + Util.warn + (Printf.sprintf + "Can't bind to host (%s:%s): %s" ai.Unix.ai_canonname port + reason); loop r) end in let listening = loop (Unix.getaddrinfo host port [ Unix.AI_SOCKTYPE From samuel.thibault at ens-lyon.org Sat Oct 1 11:14:53 2005 From: samuel.thibault at ens-lyon.org (Samuel Thibault) Date: Sat, 1 Oct 2005 17:14:53 +0200 Subject: [Unison-hackers] [unison-users] Address family not supported by protocol [socket()] In-Reply-To: <20051001150354.GY5321@bouh.residence.ens-lyon.fr> References: <20050930202739.GA19104@strontium.pps.jussieu.fr> <20051001143016.30704.qmail@web52903.mail.yahoo.com> <20051001144334.GA23848@strontium.pps.jussieu.fr> <20051001150354.GY5321@bouh.residence.ens-lyon.fr> Message-ID: <20051001151453.GA5321@bouh.residence.ens-lyon.fr> Samuel Thibault, le Sat 01 Oct 2005 17:03:54 +0200, a ?crit : > Jerome Vouillon, le Sat 01 Oct 2005 16:43:34 +0200, a ?crit : > > Hi Chuck, > > > > On Sat, Oct 01, 2005 at 10:30:16AM -0400, Chuck Farley wrote: > > > I'm using unison-2.17.1-linux-text. Which I only just > > > realized is a BETA. Damn never noticed that. Will > > > try the latest stable. > > [...] > > > strace unison -socket 9876 > > [...] > > > socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 > > > > So, this is due to the IPV6 support code which was recently added to > > Unison. The latest stable version should not have this problem. > > Indeed. > > I'm afraid I missed the whole bug report, but I guess Chuck complains > about a spurious warning to be emitted. That warning is a bit useless > indeed, here is a patch: Ah, sorry, that is not sufficient (Chuck really had an error, not a warning), here is a better patch. Index: src/remote.ml =================================================================== --- src/remote.ml (r?vision 105) +++ src/remote.ml (copie de travail) @@ -819,17 +819,17 @@ port)) | ai::r -> (* create a socket to talk to the remote host *) - let socket = Unix.socket ai.Unix.ai_family ai.Unix.ai_socktype ai.Unix.ai_protocol in - begin try + try + let socket = Unix.socket ai.Unix.ai_family ai.Unix.ai_socktype ai.Unix.ai_protocol in Unix.connect socket ai.Unix.ai_addr; initConnection socket socket with - Unix.Unix_error (_, _, reason) -> - (Util.warn - (Printf.sprintf + Unix.Unix_error (error, _, reason) -> + (if error != Unix.EAFNOSUPPORT then + Util.warn + (Printf.sprintf "Can't connect to server (%s:%s): %s" host port reason); loop r) - end in loop (Unix.getaddrinfo host port [ Unix.AI_SOCKTYPE Unix.SOCK_STREAM ])) let buildShellConnection shell host userOpt portOpt rootName termInteract = @@ -1126,9 +1126,9 @@ (Printf.sprintf "Can't find host (%s:%s)" host port)) | ai::r -> (* Open a socket to listen for queries *) - let socket = Unix.socket ai.Unix.ai_family ai.Unix.ai_socktype - ai.Unix.ai_protocol in - begin try + try + let socket = Unix.socket ai.Unix.ai_family ai.Unix.ai_socktype + ai.Unix.ai_protocol in (* Allow reuse of local addresses for bind *) Unix.setsockopt socket Unix.SO_REUSEADDR true; (* Bind the socket to portnum on the local host *) @@ -1137,13 +1137,14 @@ Unix.listen socket 1; socket with - Unix.Unix_error (_, _, reason) -> - (Util.warn - (Printf.sprintf - "Can't bind to host (%s:%s): %s" ai.Unix.ai_canonname port - reason); + Unix.Unix_error (error, _, reason) -> + (if error != Unix.EAFNOSUPPORT then + Util.warn + (Printf.sprintf + "Can't bind to host (%s:%s): %s" ai.Unix.ai_canonname port + reason); loop r) - end in + in let listening = loop (Unix.getaddrinfo host port [ Unix.AI_SOCKTYPE Unix.SOCK_STREAM ; Unix.AI_PASSIVE ]) in Util.msg "server started\n"; Regards, Samuel From bcpierce at cis.upenn.edu Tue Oct 4 09:43:11 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 4 Oct 2005 16:43:11 +0300 Subject: [Unison-hackers] [unison-users] Address family not supported by protocol [socket()] In-Reply-To: <20051001150354.GY5321@bouh.residence.ens-lyon.fr> References: <20050930202739.GA19104@strontium.pps.jussieu.fr> <20051001143016.30704.qmail@web52903.mail.yahoo.com> <20051001144334.GA23848@strontium.pps.jussieu.fr> <20051001150354.GY5321@bouh.residence.ens-lyon.fr> Message-ID: <51F804AA-11EE-4A79-AF74-A10AB8894EC1@cis.upenn.edu> I've applied this patch to the developer sources. Thanks, - B On Oct 1, 2005, at 6:03 PM, Samuel Thibault wrote: > --- remote-orig.ml 2005-10-01 16:55:40.000000000 +0200 > +++ remote.ml 2005-10-01 16:59:28.000000000 +0200 > @@ -824,9 +824,10 @@ > Unix.connect socket ai.Unix.ai_addr; > initConnection socket socket > with > - Unix.Unix_error (_, _, reason) -> > - (Util.warn > - (Printf.sprintf > + Unix.Unix_error (error, _, reason) -> > + (if error != Unix.EAFNOSUPPORT then > + Util.warn > + (Printf.sprintf > "Can't connect to server (%s:%s): %s" host > port reason); > loop r) > end > @@ -1137,11 +1138,12 @@ > Unix.listen socket 1; > socket > with > - Unix.Unix_error (_, _, reason) -> > - (Util.warn > - (Printf.sprintf > - "Can't bind to host (%s:%s): %s" > ai.Unix.ai_canonname port > - reason); > + Unix.Unix_error (error, _, reason) -> > + (if error != Unix.EAFNOSUPPORT then > + Util.warn > + (Printf.sprintf > + "Can't bind to host (%s:%s): %s" > ai.Unix.ai_canonname port > + reason); > loop r) > end in > let listening = loop (Unix.getaddrinfo host port > [ Unix.AI_SOCKTYPE > From bcpierce at cis.upenn.edu Tue Oct 4 09:46:49 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 4 Oct 2005 16:46:49 +0300 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <1128116906.25455.30.camel@cdhcp139.pingtel.com> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> Message-ID: <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> This would be easy to add, but I'm surprised that the error message itself appeared in a context where the name of the file that failed was not clear. Maybe that's a better place to fix the problem? - Benjamin On Oct 1, 2005, at 12:48 AM, Dale R. Worley wrote: > 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 > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From bcpierce at cis.upenn.edu Tue Oct 4 09:50:29 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 4 Oct 2005 16:50:29 +0300 Subject: [Unison-hackers] Need fix for chmod problem In-Reply-To: <1128116032.25455.26.camel@cdhcp139.pingtel.com> References: <1128116032.25455.26.camel@cdhcp139.pingtel.com> Message-ID: <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> I agree that the code in question looks wrong as it stands, and I've made this change in the developer sources. Trevor, Jerome -- do you agree? - Benjamin On Oct 1, 2005, at 12:33 AM, Dale R. Worley wrote: > 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 > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From bcpierce at cis.upenn.edu Tue Oct 4 09:59:18 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 4 Oct 2005 16:59:18 +0300 Subject: [Unison-hackers] unison 2.13.16 output patch In-Reply-To: <20050926210718.690cfab6@localhost.localdomain> References: <20050926210718.690cfab6@localhost.localdomain> Message-ID: <9BEDEFCD-26F8-4F05-9F6E-B25577AC835F@cis.upenn.edu> [Package maintainers: Please see below... --BCP] > 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) Thanks -- fixed. > > 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? Yep -- thanks for the patch. > > 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. > I'm a little reluctant to apply this one without the agreement of the various packagers -- the makefiles are rather delicate because they need to work on so many different machines. Any comments, folks? - Benjamin From dworley at pingtel.com Tue Oct 4 13:50:46 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Tue, 04 Oct 2005 13:50:46 -0400 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> Message-ID: <1128448246.12073.33.camel@cdhcp139.pingtel.com> On Tue, 2005-10-04 at 16:46 +0300, Benjamin Pierce wrote: > This would be easy to add, but I'm surprised that the error message > itself appeared in a context where the name of the file that failed > was not clear. Maybe that's a better place to fix the problem? > On Oct 1, 2005, at 12:48 AM, Dale R. Worley wrote: > > > 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? Let me keep my eye out for this message to appear again, and I will be more careful to check what its context is. Dale From dworley at pingtel.com Tue Oct 4 15:02:33 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Tue, 04 Oct 2005 15:02:33 -0400 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> Message-ID: <1128452554.12073.70.camel@cdhcp139.pingtel.com> On Tue, 2005-10-04 at 16:46 +0300, Benjamin Pierce wrote: > This would be easy to add, but I'm surprised that the error message > itself appeared in a context where the name of the file that failed > was not clear. Maybe that's a better place to fix the problem? Here is an example, taken from my unison.log: [END] Updating file sandbox-40/sipX/sipXpbx/doc/developer/Makefile.config.in [BGN] Updating file sandbox-49/dir-local/include/os/OsFS.h from //paradise.pingtel.com//home/dworley to /home/dworley Failed with exception Util.Transient("Destination updated during synchronization") [BGN] Updating file sandbox-49/dir-local/include/os/OsFileBase.h from //paradise.pingtel.com//home/dworley to /home/dworley [END] Updating file .gaim/blist.xml As far as I can tell, the Util.Transient exceptions are not necessarily related to the files mentioned near them in unison.log. For example: [BGN] Updating file sandbox-49/dir-local/include/os/OsConfigDb.h from //paradise.pingtel.com//home/dworley to /home/dworley [END] Copying .gaim/icons/682a502e [BGN] Updating file sandbox-49/dir-local/include/os/OsConfigEncryption.h from //paradise.pingtel.com//home/dworley to /home/dworley Failed with exception Util.Transient("The file /home/dworley/.gaim/prefs.xml\nhas been modified during synchronization: transfer aborted") [BGN] Updating file sandbox-49/dir-local/include/os/OsConnectionSocket.h from //paradise.pingtel.com//home/dworley to /home/dworley [END] Updating file .ethereal/recent [BGN] Updating file sandbox-49/dir-local/include/os/OsDatagramSocket.h from //paradise.pingtel.com//home/dworley to /home/dworley [END] Updating file .gconf/apps/evolution/mail/%gconf.xml Dale From Jerome.Vouillon at pps.jussieu.fr Wed Oct 5 08:43:01 2005 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 5 Oct 2005 14:43:01 +0200 Subject: [Unison-hackers] Need fix for chmod problem In-Reply-To: <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> References: <1128116032.25455.26.camel@cdhcp139.pingtel.com> <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> Message-ID: <20051005124301.GD29246@strontium.pps.jussieu.fr> On Tue, Oct 04, 2005 at 04:50:29PM +0300, Benjamin Pierce wrote: > I agree that the code in question looks wrong as it stands, and I've > made this change in the developer sources. > > Trevor, Jerome -- do you agree? This is a tricky issue. First, when Unison propagates a file content modification, one probably want to preserve as much as possible the permissions of the previous version of the file (which is being overwritten by Unison), even when not all permission bits are synchronized. For instance, a file which is readable by anybody should probably remain so even when no permission is synchronized. This is the reason for the special case when kind = `Set. Second, when a file or a directory is created, its permissions are not always exactly the permissions given to the mkdir or open system call: they depend on the process's umask and (for directory) on whether the parent directory has a set group ID bit set. If we want a consistent behavior, Unison should either unconditionally set the full permissions afterwards as is done now, or look at the file system to see what the permissions was set to and only update the bits which are synchronized. Third, on some filesystem, chmod can fail for some permissions. Thus, Unison should only change the values of the synchronized bits. This is not the case at the moment. Thus, I think the right fix is to change, in file fileinfo.ml, in function set, the following piece of code: `Set defDesc -> (* Set the permissions and maybe the other properties *) `Set, Props.override defDesc newDesc into: `Set defDesc -> (* Set the permissions and maybe the other properties *) `Set, Props.override (get false fspath path).desc newDesc It would probably be clearer to turn the expression "kind <> `Update" into "kind = `Set" in file props.ml. Also, this part of the code could be better documented... Dale, could you try this change? Thanks a lot for your mail. This was a good opportunity for me to think about this issue. Benjamin, could you make the change (if Dale is happy with it). I have not yet migrated to the new svn repository. -- Jerome From Jerome.Vouillon at pps.jussieu.fr Wed Oct 5 08:49:44 2005 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 5 Oct 2005 14:49:44 +0200 Subject: [Unison-hackers] unison 2.13.16 output patch In-Reply-To: <9BEDEFCD-26F8-4F05-9F6E-B25577AC835F@cis.upenn.edu> References: <20050926210718.690cfab6@localhost.localdomain> <9BEDEFCD-26F8-4F05-9F6E-B25577AC835F@cis.upenn.edu> Message-ID: <20051005124944.GE29246@strontium.pps.jussieu.fr> On Tue, Oct 04, 2005 at 04:59:18PM +0300, Benjamin Pierce wrote: > I'm a little reluctant to apply this one without the agreement of the > various packagers -- the makefiles are rather delicate because they > need to work on so many different machines. I'm not sure there is any point in building static binaries anymore. Under Linux, this is not really possible: the network name resolution library (gethostbyname, ...) cannot be linked statically. Under Windows, the text version of Unison is portable, and I'm not sure one can find a static GTK library to compile statically the GUI version. I suspect the "STATIC=true" compile option does not work at all at the moment. -- Jerome From dworley at pingtel.com Wed Oct 5 09:50:42 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Wed, 05 Oct 2005 09:50:42 -0400 Subject: [Unison-hackers] Need fix for chmod problem In-Reply-To: <20051005124301.GD29246@strontium.pps.jussieu.fr> References: <1128116032.25455.26.camel@cdhcp139.pingtel.com> <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> <20051005124301.GD29246@strontium.pps.jussieu.fr> Message-ID: <1128520242.12073.95.camel@cdhcp139.pingtel.com> On Wed, 2005-10-05 at 14:43 +0200, Jerome Vouillon wrote: > This is a tricky issue. Oh, yes. > First, when Unison propagates a file content modification, one > probably want to preserve as much as possible the permissions of the > previous version of the file (which is being overwritten by Unison), > even when not all permission bits are synchronized. [Etc.] There are other cases as well, including the one I am stuck with. Namely, where the "permissions" as seen by the Posix interface are partly or largely fabricated, and chomd() is partly or largely ineffective, or as in my case, entirely forbidden. IMHO, I think there should be a setting that would fill Unison with despair, er, tell it to ignore permissions issues entirely, and leave them to the underlying implementation to fake, on the grounds that the implementation (which understands them) will do a better job of it than Unison (which doesn't understand them). (Note that "times = false" has this sort of effect on modification times.) It seems to me that "perms = 0" is the obvious candidate for this workaround, although your argument suggests that the case "real Posix with perms = 0" is not quite the same thing as "don't fiddle with permissions issues". > Thus, I think the right fix is to change, in file fileinfo.ml, in > function set, the following piece of code: > > `Set defDesc -> > (* Set the permissions and maybe the other properties *) > `Set, Props.override defDesc newDesc > > into: > > `Set defDesc -> > (* Set the permissions and maybe the other properties *) > `Set, Props.override (get false fspath path).desc newDesc This may well be good, but given the comment on defDesc, I can assure you that it will cause an error 100% of the time it is called. > Dale, could you try this change? Thanks a lot for your mail. This > was a good opportunity for me to think about this issue. Well, I wouldn't even know how to start building it. But there's no reason to test it -- if you can assure me that "perms = 0" will prevent chmod from ever being called (on a target file/directory), then it will work, and otherwise it will fail. Dale From Jerome.Vouillon at pps.jussieu.fr Wed Oct 5 10:43:50 2005 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Wed, 5 Oct 2005 16:43:50 +0200 Subject: [Unison-hackers] Need fix for chmod problem In-Reply-To: <1128520242.12073.95.camel@cdhcp139.pingtel.com> References: <1128116032.25455.26.camel@cdhcp139.pingtel.com> <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> <20051005124301.GD29246@strontium.pps.jussieu.fr> <1128520242.12073.95.camel@cdhcp139.pingtel.com> Message-ID: <20051005144350.GA6797@strontium.pps.jussieu.fr> On Wed, Oct 05, 2005 at 09:50:42AM -0400, Dale R. Worley wrote: > There are other cases as well, including the one I am stuck with. > Namely, where the "permissions" as seen by the Posix interface are > partly or largely fabricated, and chomd() is partly or largely > ineffective, or as in my case, entirely forbidden. Are you sure chmod is completely forbidden in your case? I would have thought that only the modification of some bits was forbidden. Can you try to create a file and use the chmod Unix command in a way that let its permissions unchanged. The following two commands should do the job. Does the chmod fail? touch foobar chmod +r foobar -- Jerome From dworley at pingtel.com Thu Oct 6 10:09:14 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Thu, 06 Oct 2005 10:09:14 -0400 Subject: [Unison-hackers] Need fix for chmod problem In-Reply-To: <20051005144350.GA6797@strontium.pps.jussieu.fr> References: <1128116032.25455.26.camel@cdhcp139.pingtel.com> <17B37871-1681-40D6-9615-F3B665C1CF9A@cis.upenn.edu> <20051005124301.GD29246@strontium.pps.jussieu.fr> <1128520242.12073.95.camel@cdhcp139.pingtel.com> <20051005144350.GA6797@strontium.pps.jussieu.fr> Message-ID: <1128607754.15737.33.camel@cdhcp139.pingtel.com> On Wed, 2005-10-05 at 16:43 +0200, Jerome Vouillon wrote: > Can you try to create a file and use the chmod Unix command in a way > that let its permissions unchanged. > The following two commands should do the job. Does the chmod fail? > touch foobar > chmod +r foobar Yes, the chmod fails with "chmod: changing permissions of `[...]': Operation not permitted". I've attached a slightly edited shell transcript of my attempt to use Unison, and of doing the test chmod. I've also attached the .prf file I am using. Dale -------------- next part -------------- $ unison pingtel-to-pingpdc -batch Contacting server... Looking for changes Documents Documents/search_files Documents/TUI_Flowcharts Documents/Snom Documents/Grandstream Documents/Polycom Documents/Cisco Documents/rfcs Documents/internet-drafts Documents/Sipura Documents/SIP-B Temp Temp/Wal-Mart Temp/Local Folders Temp/0pligyyb.slt Temp/call-park-files Temp Temp/Wal-Mart Temp/Local Folders Temp/call-park-files Temp/0pligyyb.slt Documents Documents/TUI_Flowcharts Documents/Snom Documents/Sipura Documents/SIP-B Documents/search_files Documents/rfcs Documents/Polycom Documents/internet-drafts Documents/Grandstream Documents/Cisco Reconciling changes Pingpdc dworley new file ----> Documents/internet-drafts/draft-ietf-sipping-gruu-reg-event-00.txt Pingpdc : new file modified at 9:52 on 4 Oct, 2005 size 20336 unknown permissions dworley : absent new file ----> Documents/rfcs/rfc4168.txt Pingpdc : new file modified at 10:47 on 5 Oct, 2005 size 21079 unknown permissions dworley : absent Propagating updates UNISON started propagating changes at 09:58:48 on 06 Oct 2005 [BGN] Copying Documents/internet-drafts/draft-ietf-sipping-gruu-reg-event-00.txt from /home/dworley/Pingpdc to /pingpdc/Data/Users/dworley [BGN] Copying Documents/rfcs/rfc4168.txt from /home/dworley/Pingpdc to /pingpdc/Data/Users/dworley Failed with exception Util.Transient("Error in setting permissions:\nOperation not permitted [chmod(/pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp)]") Failed: Error in setting permissions: Operation not permitted [chmod(/pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp)] Failed with exception Util.Transient("Error in setting permissions:\nOperation not permitted [chmod(/pingpdc/Data/Users/dworley/Documents/rfcs/.#rfc4168.txt.0.unison.tmp)]") Failed: Error in setting permissions: Operation not permitted [chmod(/pingpdc/Data/Users/dworley/Documents/rfcs/.#rfc4168.txt.0.unison.tmp)] UNISON finished propagating changes at 09:58:48 on 06 Oct 2005 Saving synchronizer state Synchronization complete $ cat /dev/null >/pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp [[ 777 is the mode displayed by 'ls' for all files in this directory. ]] $ chmod 777 /pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp chmod: changing permissions of `/pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp': Operation not permitted $ chmod +r /pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp chmod: changing permissions of `/pingpdc/Data/Users/dworley/Documents/internet-drafts/.#draft-ietf-sipping-gruu-reg-event-00.txt.0.unison.tmp': Operation not permitted -------------- next part -------------- root = /home/dworley/Pingpdc root = /pingpdc/Data/Users/dworley # For some reason, Linux can't set the time on an SMB share. times = false # And the permissions are meaningless. perms = 0 # Do not copy user/group, since both accounts are users on their machines. # This is unison 2.9.1. servercmd = /home/dworley/bin/i686/unison # Do not synchronize backup files. ignore = Name *~ ignore = Name .*~ From jdunn14 at hotpop.com Thu Oct 6 14:10:39 2005 From: jdunn14 at hotpop.com (Joseph Dunn) Date: Thu, 6 Oct 2005 12:10:39 -0600 Subject: [Unison-hackers] unison 2.13.16 output patch In-Reply-To: <20051005124944.GE29246@strontium.pps.jussieu.fr> References: <20050926210718.690cfab6@localhost.localdomain> <9BEDEFCD-26F8-4F05-9F6E-B25577AC835F@cis.upenn.edu> <20051005124944.GE29246@strontium.pps.jussieu.fr> Message-ID: <20051006121039.6b8b13ca@localhost.localdomain> Well, actually the patch I submitted made STATIC=true work, at least under Linux (the only place I need it). Basically, I'm running unison inside a chroot'd environment on the server side and I'm trying to keep the number of libraries needed in the environment to a minimum. A statically compiled unison in a directory like /tmp/blah allows me to run a command something like the following: HOME=. sudo chroot /tmp/blah ./unison.linux-static-textui -server It's not critical to have the patch added, but I found it useful and thought others might. -Joseph Dunn On Wed, 5 Oct 2005 14:49:44 +0200 Jerome Vouillon wrote: > On Tue, Oct 04, 2005 at 04:59:18PM +0300, Benjamin Pierce wrote: > > I'm a little reluctant to apply this one without the agreement of the > > various packagers -- the makefiles are rather delicate because they > > need to work on so many different machines. > > I'm not sure there is any point in building static binaries anymore. > Under Linux, this is not really possible: the network name resolution > library (gethostbyname, ...) cannot be linked statically. Under > Windows, the text version of Unison is portable, and I'm not sure one > can find a static GTK library to compile statically the GUI version. > > I suspect the "STATIC=true" compile option does not work at all at the > moment. > > -- Jerome > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From bcpierce at cis.upenn.edu Fri Oct 7 05:34:39 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 7 Oct 2005 10:34:39 +0100 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <1128452554.12073.70.camel@cdhcp139.pingtel.com> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> <1128452554.12073.70.camel@cdhcp139.pingtel.com> Message-ID: <9438EC85-7510-4A14-8750-0EFF9861EAD6@cis.upenn.edu> Thanks. What version of Unison are you using, BTW? - Benjamin On Oct 4, 2005, at 8:02 PM, Dale R. Worley wrote: > On Tue, 2005-10-04 at 16:46 +0300, Benjamin Pierce wrote: > > >> This would be easy to add, but I'm surprised that the error message >> itself appeared in a context where the name of the file that failed >> was not clear. Maybe that's a better place to fix the problem? >> >> > > Here is an example, taken from my unison.log: > > [END] Updating file sandbox-40/sipX/sipXpbx/doc/developer/ > Makefile.config.in > [BGN] Updating file sandbox-49/dir-local/include/os/OsFS.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > Failed with exception Util.Transient("Destination updated during > synchronization") > [BGN] Updating file sandbox-49/dir-local/include/os/OsFileBase.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > [END] Updating file .gaim/blist.xml > > As far as I can tell, the Util.Transient exceptions are not > necessarily > related to the files mentioned near them in unison.log. For example: > > [BGN] Updating file sandbox-49/dir-local/include/os/OsConfigDb.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > [END] Copying .gaim/icons/682a502e > [BGN] Updating file sandbox-49/dir-local/include/os/ > OsConfigEncryption.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > Failed with exception Util.Transient("The file /home/dworley/.gaim/ > prefs.xml\nhas been modified during synchronization: transfer > aborted") > [BGN] Updating file sandbox-49/dir-local/include/os/ > OsConnectionSocket.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > [END] Updating file .ethereal/recent > [BGN] Updating file sandbox-49/dir-local/include/os/OsDatagramSocket.h > from //paradise.pingtel.com//home/dworley > to /home/dworley > [END] Updating file .gconf/apps/evolution/mail/%gconf.xml > > Dale > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > From dworley at pingtel.com Fri Oct 7 09:51:59 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Fri, 07 Oct 2005 09:51:59 -0400 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <9438EC85-7510-4A14-8750-0EFF9861EAD6@cis.upenn.edu> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> <1128452554.12073.70.camel@cdhcp139.pingtel.com> <9438EC85-7510-4A14-8750-0EFF9861EAD6@cis.upenn.edu> Message-ID: <1128693119.15737.91.camel@cdhcp139.pingtel.com> On Fri, 2005-10-07 at 10:34 +0100, Benjamin Pierce wrote: > Thanks. What version of Unison are you using, BTW? 2.9.1 Dale From bcpierce at cis.upenn.edu Fri Oct 7 20:30:13 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 7 Oct 2005 20:30:13 -0400 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <1128693119.15737.91.camel@cdhcp139.pingtel.com> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> <1128452554.12073.70.camel@cdhcp139.pingtel.com> <9438EC85-7510-4A14-8750-0EFF9861EAD6@cis.upenn.edu> <1128693119.15737.91.camel@cdhcp139.pingtel.com> Message-ID: <8D6AD6D5-CFC2-459F-908F-BE2F8118CC9C@cis.upenn.edu> That's a pretty old version! I looked at the sources, but the error messages have changed quite a bit since then so it wasn't clear what to fix or indeed if anything still needed fixing. Regards, - Benjamin On Oct 7, 2005, at 9:51 AM, Dale R. Worley wrote: > On Fri, 2005-10-07 at 10:34 +0100, Benjamin Pierce wrote: > >> Thanks. What version of Unison are you using, BTW? >> > > 2.9.1 > > Dale > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From dworley at pingtel.com Sat Oct 8 15:17:17 2005 From: dworley at pingtel.com (Dale R. Worley) Date: Sat, 08 Oct 2005 15:17:17 -0400 Subject: [Unison-hackers] Error message "Destination updated during synchronization" does not give file name In-Reply-To: <8D6AD6D5-CFC2-459F-908F-BE2F8118CC9C@cis.upenn.edu> References: <1128116906.25455.30.camel@cdhcp139.pingtel.com> <14E40456-F689-440A-8309-995852B1AB15@cis.upenn.edu> <1128452554.12073.70.camel@cdhcp139.pingtel.com> <9438EC85-7510-4A14-8750-0EFF9861EAD6@cis.upenn.edu> <1128693119.15737.91.camel@cdhcp139.pingtel.com> <8D6AD6D5-CFC2-459F-908F-BE2F8118CC9C@cis.upenn.edu> Message-ID: <1128799037.21489.0.camel@cdhcp139.pingtel.com> On Fri, 2005-10-07 at 20:30 -0400, Benjamin Pierce wrote: > That's a pretty old version! I looked at the sources, but the error > messages have changed quite a bit since then so it wasn't clear what > to fix or indeed if anything still needed fixing. I'll install the "latest stable version" and try again... Dale From jcc3 at comcast.net Tue Oct 11 06:06:08 2005 From: jcc3 at comcast.net (Joseph Collins) Date: Tue, 11 Oct 2005 06:06:08 -0400 Subject: [Unison-hackers] relative path error in 2.17.1 In-Reply-To: <42C666C9.6050202@comcast.net> References: <200506272141.j5RLffvO029964@rhizome.seas.upenn.edu> <42C666C9.6050202@comcast.net> Message-ID: <434B8E90.5050006@comcast.net> hi --- On Win2K I have had good luck building up to 2.13.16 but 2.17.1 fails with : [BGN] Copying x/unison/hm/zzz_err.prf from e:/joe to n:/ Failed: The path '/unison/hm' is not a relative path Partial "-debug all" details follow. Is there a problem with fullLocalPath ? --- joe ================ UNISON started propagating changes at 05:51:45 on 11 Oct 2005 [BGN] Updating file x/unison/hm/zzz_err.prf from e:/joe to n:/ [files] copy e:/joe x/unison/hm/zzz_err.prf ---> n:/ x/unison/hm/zzz_err.prf [fspath] Os.findWorkingDir(n:/,x/unison/hm/zzz_err.prf) = (n:/x/unison/hm,zzz_err.prf) [update] updateArchiveLocal e:/joe x/unison/hm/zzz_err.prf [pred] ignore 'x/unison/hm/zzz_err.prf' = false [update] updateArchiveLocal n:/ x/unison/hm/zzz_err.prf [pred] ignore 'x/unison/hm/zzz_err.prf' = false [files] copyRec x/unison/hm/zzz_err.prf --> .#zzz_err.prf.5eda01.unison.tmp (really to zzz_err.prf) [abort] Checking line 0 [copy] copyRegFile(e:/joe,x/unison/hm/zzz_err.prf) -> (n:/,zzz_err.prf,n:/x/unison/hm,.#zzz_err.prf.5eda01.unison.tmp,modified on 2005-10-11 at 5:32:18 size 183 unknown permissions) [copy] copylocal (e:/joe,x/unison/hm/zzz_err.prf) to (n:/x/unison/hm, .#zzz_err.prf.5eda01.unison.tmp) [abort] Checking line 0 [props] Setting permissions for n:/x/unison/hm/.#zzz_err.prf.5eda01.unison.tmp to unknown permissions (666/0) [update] replaceArchiveLocal n:/ x/unison/hm/zzz_err.prf [files] rename(root=n:/, pathOld=.#zzz_err.prf.5eda01.unison.tmp, pathNew=zzz_err.prf) [update] checkNoUpdatesLocal n:/ x/unison/hm/zzz_err.prf [update] buildUpdate: n:/x/unison/hm/zzz_err.prf [update] checkContentsChange: archive : stamp is ctime (1129019897.000000) / archStamp is ctime (1129019897.000000) / info.ctime (1129019897.000000) [update] archive digest = (ef3a8ff2cfb9313b3ac58ef965d2179f,) current digest = (ef3a8ff2cfb9313b3ac58ef965d2179f,) [files] Renaming .#zzz_err.prf.5eda01.unison.tmp to zzz_err.prf in n:/x/unison/hm ; root is n:/ [thread] Exception caught by Thread.unwindProtect: The path '/unison/hm' is not a relative path [files] DeleteLocal [n:/] (n:/x/unison/hm, .#zzz_err.prf.5eda01.unison.tmp) [thread] Exception caught by Thread.unwindProtect: The path '/unison/hm' is not a relative path Failed: The path '/unison/hm' is not a relative path UNISON finished propagating changes at 05:51:45 on 11 Oct 2005 ================ From Jerome.Vouillon at pps.jussieu.fr Tue Oct 11 06:33:24 2005 From: Jerome.Vouillon at pps.jussieu.fr (Jerome Vouillon) Date: Tue, 11 Oct 2005 12:33:24 +0200 Subject: [Unison-hackers] relative path error in 2.17.1 In-Reply-To: <434B8E90.5050006@comcast.net> References: <200506272141.j5RLffvO029964@rhizome.seas.upenn.edu> <42C666C9.6050202@comcast.net> <434B8E90.5050006@comcast.net> Message-ID: <20051011103324.GA13455@strontium.pps.jussieu.fr> Hi, On Tue, Oct 11, 2005 at 06:06:08AM -0400, Joseph Collins wrote: > On Win2K I have had good luck building up to 2.13.16 but 2.17.1 fails with : > > [BGN] Copying x/unison/hm/zzz_err.prf > from e:/joe > to n:/ > Failed: The path '/unison/hm' is not a relative path > > Partial "-debug all" details follow. Is there a problem with > fullLocalPath ? Indeed, fullLocalPath seems to have problems with Windows-style path such as "n:/". Thanks for the bug report! -- Jerome From alan.schmitt at polytechnique.org Wed Oct 12 09:57:27 2005 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Wed, 12 Oct 2005 15:57:27 +0200 Subject: [Unison-hackers] patch to allow partial force or prefer Message-ID: <77E2562C-CC57-4281-819E-B15225D87208@polytechnique.org> Hello, Here is a patch that allows to state that some files should always be sent from one side to the other ("forcepartial") or that conflicts for some files should always resolved for a given root ("preferpartial"). The syntax is like one of predicates: to always force files in ".b" to be propagated from b, one writes: forcepartial = Name *.b -> b As for the force and prefer options, one may choose "newer" or "older" as the root. Caveats: - It was much simpler to keep the old "force" and "prefer" options natively instead of trying to implement them using the partial versions. As specified in the help, forcepartial overrides force, and preferpartial overrides prefer, for the specified files. - The test that the roots make sense is not made until synchronization start. To do it at start time one would need a way to extract all the associations from a Pred.t. I'll look at this next. Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: partial.patch Type: application/octet-stream Size: 4892 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20051012/8ad6615f/partial.obj -------------- next part -------------- -- The hacker: someone who figured things out and made something cool happen. .O. ..O OOO -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20051012/8ad6615f/PGP.pgp From bcpierce at cis.upenn.edu Wed Oct 12 10:12:24 2005 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Wed, 12 Oct 2005 10:12:24 -0400 Subject: [Unison-hackers] [unison-svn] r106 - trunk/src Message-ID: <200510121412.j9CECOAJ031651@canfield.cis.upenn.edu> Author: bcpierce Date: 2005-10-12 10:12:21 -0400 (Wed, 12 Oct 2005) New Revision: 106 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/props.ml trunk/src/recon.ml trunk/src/remote.ml trunk/src/transport.ml trunk/src/transport.mli trunk/src/uigtk.ml trunk/src/uigtk2.ml trunk/src/uimacbridge.ml trunk/src/uitext.ml Log: Applied patch from Alan Schmitt adding forcepatial and preferpartial preferences, which behave like 'force' and 'prefer' but can be specified on a per-path basis (see documentation for details). Applied fix to IPv6 code from Samuel Thibault Corrected Props.set as suggested by Dale Worley Small fix to the text UI from Joseph Dunn. From bcpierce at cis.upenn.edu Wed Oct 12 10:13:00 2005 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Wed, 12 Oct 2005 10:13:00 -0400 Subject: [Unison-hackers] patch to allow partial force or prefer In-Reply-To: <77E2562C-CC57-4281-819E-B15225D87208@polytechnique.org> References: <77E2562C-CC57-4281-819E-B15225D87208@polytechnique.org> Message-ID: Cool. Thanks for the patch! - B On Oct 12, 2005, at 9:57 AM, Alan Schmitt wrote: > Hello, > > Here is a patch that allows to state that some files should always > be sent from one side to the other ("forcepartial") or that > conflicts for some files should always resolved for a given root > ("preferpartial"). > > The syntax is like one of predicates: to always force files in ".b" > to be propagated from b, one writes: > forcepartial = Name *.b -> b > > As for the force and prefer options, one may choose "newer" or > "older" as the root. > > Caveats: > - It was much simpler to keep the old "force" and "prefer" options > natively instead of trying to implement them using the partial > versions. As specified in the help, forcepartial overrides force, > and preferpartial overrides prefer, for the specified files. > - The test that the roots make sense is not made until > synchronization start. To do it at start time one would need a way > to extract all the associations from a Pred.t. I'll look at this next. > > Alan > > > > > > -- The hacker: someone who figured things out and made something > cool happen. > .O. > ..O > OOO > > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > From alan.schmitt at polytechnique.org Wed Oct 12 11:22:25 2005 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Wed, 12 Oct 2005 17:22:25 +0200 Subject: [Unison-hackers] checking the roots for preferpartial and forcepartial Message-ID: <3F36064F-0FB8-42C2-9CD5-6DDC4B5DC4CF@polytechnique.org> Hi, Here is a patch that checks whether the roots are well formed for preferpartial and forcepartial. It adds a "Pred.extern_associated_strings" function to get all the associated strings of a Pred.t. This also does some code reorganization: lookupPreferredRoot does not check for the "times" option when "newer" or "older" is used, this is now done by "checkThatPreferredRootIsValid" (so we only need to do it once when we start). This also fixes a small bug: if one had: prefer = newer then the check that "times=true" would not be done. Alan -------------- next part -------------- A non-text attachment was scrubbed... Name: checkroots.patch Type: application/octet-stream Size: 3595 bytes Desc: not available Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20051012/7aba9019/checkroots.obj -------------- next part -------------- -- The hacker: someone who figured things out and made something cool happen. .O. ..O OOO -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.seas.upenn.edu/pipermail/unison-hackers/attachments/20051012/7aba9019/PGP.pgp From bcpierce at cis.upenn.edu Wed Oct 12 13:13:36 2005 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Wed, 12 Oct 2005 13:13:36 -0400 Subject: [Unison-hackers] [unison-svn] r107 - trunk/src Message-ID: <200510121713.j9CHDaMR001194@canfield.cis.upenn.edu> Author: bcpierce Date: 2005-10-12 13:13:34 -0400 (Wed, 12 Oct 2005) New Revision: 107 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/pred.ml trunk/src/pred.mli trunk/src/recon.ml Log: Applied another patch from Alan Schmitt improving the implementation of forcepatial and preferpartial. From jcc3 at comcast.net Thu Oct 13 12:10:34 2005 From: jcc3 at comcast.net (Joseph Collins) Date: Thu, 13 Oct 2005 12:10:34 -0400 Subject: [Unison-hackers] relative path error in 2.17.1 Message-ID: <000801c5d010$a71e6b90$460e3f80@nae.ds.army.mil> Since string index begins at 0, perhaps the offset argument of String.sub in fullLocalPath should be r and not r+1, as follows, if the intent is to strip roots from fspaths. I am not sure what impact this has on all filesystems. unison-2.17.1$ diff -U 9 fspath-0.ml fspath.ml --- fspath-0.ml 2005-08-11 20:26:59.000000000 -0400 +++ fspath.ml 2005-10-13 11:11:24.791390500 -0400 @@ -209,19 +209,19 @@ let rec fullLocalPath roots fspath path = let r = String.length roots in let fspaths = toString fspath in if fspaths = roots then path else let parent = Path.parent path in if Path.isEmpty parent then let name = Name.fromString (Path.toString path) in - Path.child (Path.fromString (String.sub fspaths (r+1) (String.length fspaths - r - 1))) name + Path.child (Path.fromString (String.sub fspaths r (String.length fspaths - r - 1))) name else let localParentPath = fullLocalPath roots fspath parent in match Path.finalName (Path.magic' path) with Some n -> Path.child localParentPath n | None -> localParentPath (* Return the canonical fspath of a filename (string), relative to the *) (* current host, current directory. *) unison-2.17.1$ From bifrostspider at yahoo.com Thu Oct 13 14:45:30 2005 From: bifrostspider at yahoo.com (dan c) Date: Thu, 13 Oct 2005 11:45:30 -0700 (PDT) Subject: [Unison-hackers] missing newlines with -silent Message-ID: <20051013184531.10356.qmail@web51507.mail.yahoo.com> running unison -silent does not put newlines after errors: $ ./unison.exe -batch -silent ~/test/1 ~/test/2 changed <-?-> changed f1 new file <-?-> new file f2 the output should be: $ ./unison.exe -batch -silent ~/test/1 ~/test/2 changed <-?-> changed f1 new file <-?-> new file f2 (this still occurs using r107) --dan __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From jcc3 at comcast.net Fri Oct 14 04:17:02 2005 From: jcc3 at comcast.net (Joseph Collins) Date: Fri, 14 Oct 2005 04:17:02 -0400 Subject: [Unison-hackers] relative path error in 2.17.1 Message-ID: <434F697E.1070905@comcast.net> Mea culpa . . . this is not the solution: "Since string index begins at 0, perhaps the offset argument of String.sub in fullLocalPath should be r and not r+1, as follows, if the intent is to strip roots from fspaths. " It cures one malfunction and introduces others. From trevor at research.att.com Thu Oct 20 14:29:07 2005 From: trevor at research.att.com (trevor@research.att.com) Date: Thu, 20 Oct 2005 14:29:07 -0400 Subject: [Unison-hackers] [unison-svn] r108 - in trunk/src: . uimac uimac/English.lproj/MainMenu.nib Message-ID: <200510201829.j9KIT7n9008693@canfield.cis.upenn.edu> Author: trevor Date: 2005-10-20 14:29:04 -0400 (Thu, 20 Oct 2005) New Revision: 108 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml trunk/src/terminal.ml trunk/src/terminal.mli trunk/src/uimac/English.lproj/MainMenu.nib/classes.nib trunk/src/uimac/English.lproj/MainMenu.nib/info.nib trunk/src/uimac/English.lproj/MainMenu.nib/objects.nib trunk/src/uimac/MyController.h trunk/src/uimac/MyController.m trunk/src/uimacbridge.ml Log: Applied Ben Willmore's patches for OS X: * Recognize more ssh password prompts * Recognize and prompt for ssh passphrase if asked by ssh * Fixed bug where GUI would get confused if invoked on the command line with a profile. From bcpierce at cis.upenn.edu Sun Oct 23 13:36:34 2005 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 23 Oct 2005 13:36:34 -0400 Subject: [Unison-hackers] [unison-svn] r109 - trunk/src Message-ID: <200510231736.j9NHaYXL024623@canfield.cis.upenn.edu> Author: bcpierce Date: 2005-10-23 13:36:32 -0400 (Sun, 23 Oct 2005) New Revision: 109 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: Increment major version number (forgot to do this when the new preferences were added recently)