From bcpierce at cis.upenn.edu Sun Jun 4 20:33:25 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 4 Jun 2006 20:33:25 -0400 Subject: [Unison-hackers] [unison-svn] r160 - in trunk/src: . ubase Message-ID: <200606050033.k550XP8L016551@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-04 20:33:24 -0400 (Sun, 04 Jun 2006) New Revision: 160 Modified: trunk/src/RECENTNEWS trunk/src/clroot.ml trunk/src/files.ml trunk/src/fspath.ml trunk/src/globals.ml trunk/src/globals.mli trunk/src/mkProjectInfo.ml trunk/src/props.ml trunk/src/remote.ml trunk/src/stasher.ml trunk/src/transfer.ml trunk/src/transport.ml trunk/src/ubase/Makefile trunk/src/ubase/myMap.ml trunk/src/ubase/prefs.ml trunk/src/ubase/rx.ml trunk/src/ubase/trace.ml trunk/src/uicommon.ml trunk/src/update.ml Log: * Removed -mergebatch preference. (I never found it very useful, and its semantics were confusing.) Bumped minor version number. * Refined debugging code so that the verbosity of individual modules can be controlled separately. Instead of just putting '-debug verbose' on the command line, you can put '-debug update+', which causes all the extra messages in the Update module, but not other modules, to be printed. Putting '-debug verbose' causes all modules to print with maximum verbosity. From bcpierce at cis.upenn.edu Sun Jun 4 20:42:50 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Sun, 4 Jun 2006 20:42:50 -0400 Subject: [Unison-hackers] [unison-svn] r161 - in trunk/src: . lwt ubase Message-ID: <200606050042.k550goIw016619@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-04 20:42:48 -0400 (Sun, 04 Jun 2006) New Revision: 161 Modified: trunk/src/BUGS.txt trunk/src/CONTRIB trunk/src/COPYING trunk/src/INSTALL trunk/src/INSTALL.gtk2 trunk/src/INSTALL.win32 trunk/src/INSTALL.win32-cygwin-gnuc trunk/src/INSTALL.win32-msvc trunk/src/Makefile trunk/src/Makefile.OCaml trunk/src/NEWS trunk/src/README trunk/src/RECENTNEWS trunk/src/ROADMAP.txt trunk/src/TODO.txt trunk/src/abort.ml trunk/src/abort.mli trunk/src/case.ml trunk/src/case.mli trunk/src/checksum.ml trunk/src/checksum.mli trunk/src/clroot.ml trunk/src/clroot.mli trunk/src/common.ml trunk/src/common.mli trunk/src/copy.ml trunk/src/copy.mli trunk/src/fileinfo.ml trunk/src/fileinfo.mli trunk/src/files.ml trunk/src/files.mli trunk/src/fileutil.ml trunk/src/fileutil.mli trunk/src/fingerprint.ml trunk/src/fingerprint.mli trunk/src/fspath.ml trunk/src/fspath.mli trunk/src/globals.ml trunk/src/globals.mli trunk/src/linkgtk.ml trunk/src/linkgtk2.ml trunk/src/linktext.ml trunk/src/linktk.ml trunk/src/lock.ml trunk/src/lock.mli trunk/src/lwt/pqueue.ml trunk/src/lwt/pqueue.mli trunk/src/main.ml trunk/src/mkProjectInfo.ml trunk/src/name.ml trunk/src/name.mli trunk/src/os.ml trunk/src/os.mli trunk/src/osx.ml trunk/src/osx.mli trunk/src/osxsupport.c trunk/src/path.ml trunk/src/path.mli trunk/src/pixmaps.ml trunk/src/pred.ml trunk/src/pred.mli trunk/src/props.ml trunk/src/props.mli trunk/src/recon.ml trunk/src/recon.mli trunk/src/remote.ml trunk/src/remote.mli trunk/src/sortri.ml trunk/src/sortri.mli trunk/src/stasher.ml trunk/src/stasher.mli trunk/src/strings.mli trunk/src/transfer.ml trunk/src/transfer.mli trunk/src/transport.ml trunk/src/transport.mli trunk/src/tree.ml trunk/src/tree.mli trunk/src/ubase/prefs.ml trunk/src/ubase/prefs.mli trunk/src/ubase/rx.ml trunk/src/ubase/rx.mli trunk/src/ubase/safelist.ml trunk/src/ubase/safelist.mli trunk/src/ubase/trace.ml trunk/src/ubase/trace.mli trunk/src/ubase/uarg.ml trunk/src/ubase/util.ml trunk/src/ubase/util.mli trunk/src/ui.mli trunk/src/uicommon.ml trunk/src/uicommon.mli trunk/src/uigtk.ml trunk/src/uigtk.mli trunk/src/uigtk2.ml trunk/src/uigtk2.mli trunk/src/uitext.ml trunk/src/uitext.mli trunk/src/update.ml trunk/src/update.mli trunk/src/uutil.ml trunk/src/uutil.mli trunk/src/xferhint.ml trunk/src/xferhint.mli Log: * Updated copyright information and subversion tags in file headers From bcpierce at cis.upenn.edu Mon Jun 5 11:04:40 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 5 Jun 2006 11:04:40 -0400 Subject: [Unison-hackers] [unison-svn] r162 - trunk/src Message-ID: <200606051504.k55F4eQl025760@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-05 11:04:39 -0400 (Mon, 05 Jun 2006) New Revision: 162 Modified: trunk/src/.depend trunk/src/RECENTNEWS trunk/src/files.ml trunk/src/mkProjectInfo.ml trunk/src/path.mli trunk/src/stasher.ml trunk/src/stasher.mli trunk/src/transport.ml trunk/src/update.ml Log: * Fixed some problems in the backup and merging code, for better cooperation with external Harmony instances. From bcpierce at cis.upenn.edu Mon Jun 5 22:26:24 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Mon, 5 Jun 2006 22:26:24 -0400 Subject: [Unison-hackers] [unison-svn] r163 - trunk/src Message-ID: <200606060226.k562QOsa032332@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-05 22:26:24 -0400 (Mon, 05 Jun 2006) New Revision: 163 Modified: trunk/src/RECENTNEWS trunk/src/TODO.txt trunk/src/mkProjectInfo.ml trunk/src/remote.ml Log: * Bumped version number. From bcpierce at cis.upenn.edu Tue Jun 13 15:01:21 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Tue, 13 Jun 2006 15:01:21 -0400 Subject: [Unison-hackers] [unison-svn] r164 - in trunk: . src Message-ID: <200606131901.k5DJ1LVs023416@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-13 15:01:21 -0400 (Tue, 13 Jun 2006) New Revision: 164 Removed: trunk/src/uigtk.ml trunk/src/uigtk.mli Modified: trunk/Makefile trunk/src/INSTALL trunk/src/Makefile.OCaml trunk/src/RECENTNEWS trunk/src/files.ml trunk/src/mkProjectInfo.ml trunk/src/uigtk2.ml trunk/src/uitext.ml Log: * Removed UISTYLE=gtk option (having received reports that the old gtk interface doesn't compile any more in any case). UISTYLE=gtk2 should still work. * Workaround for a bug compiling gtk2 user interface against current versions of gtk2+ libraries. From zpetkovic at acm.org Tue Jun 13 18:13:05 2006 From: zpetkovic at acm.org (Zvezdan Petkovic) Date: Tue, 13 Jun 2006 18:13:05 -0400 Subject: [Unison-hackers] [unison-svn] r164 - in trunk: . src In-Reply-To: <200606131901.k5DJ1LVs023416@canfield.cis.upenn.edu> References: <200606131901.k5DJ1LVs023416@canfield.cis.upenn.edu> Message-ID: <20060613221305.GA7396@petkovic.homeip.net> On Tue, Jun 13, 2006 at 03:01:21PM -0400, bcpierce at cis.upenn.edu wrote: > Log: > * Removed UISTYLE=gtk option (having received reports that the old gtk > interface doesn't compile any more in any case). UISTYLE=gtk2 should > still work. Benjamin, UISTYLE=gtk is the _ONLY_ GUI style on OpenBSD. There's no lablgtk2 port for OpenBSD and I always built it with lablgtk. It works just fine as of 2.12 version of Unison. I have supplied the patches that made it compile with GTK when it was broken at one moment. Are you sure it is broken again in later versions? I definitely wouldn't like to see this option go. I'll ask the maintainer of lablgtk port on OpenBSD to upgrade to lablgtk2, but I'd also like to update the port of Unison, which will be prevented by this change. Here's my proposal. I'm going to try to compile the latest stable and beta on OpenBSD. If they work with lablgtk, would you be willing to roll this change back? Zvezdan Petkovic From bcpierce at cis.upenn.edu Tue Jun 13 18:57:10 2006 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 13 Jun 2006 18:57:10 -0400 Subject: [Unison-hackers] [unison-svn] r164 - in trunk: . src In-Reply-To: <20060613221305.GA7396@petkovic.homeip.net> References: <200606131901.k5DJ1LVs023416@canfield.cis.upenn.edu> <20060613221305.GA7396@petkovic.homeip.net> Message-ID: > I'm going to try to compile the latest stable and beta on OpenBSD. > If they work with lablgtk, would you be willing to roll this change > back? Of course. I wasn't aware that it was working (and used) someplace. The change can easily be undone. - B From zpetkovic at acm.org Wed Jun 14 07:04:56 2006 From: zpetkovic at acm.org (Zvezdan Petkovic) Date: Wed, 14 Jun 2006 07:04:56 -0400 Subject: [Unison-hackers] [unison-svn] r164 - in trunk: . src In-Reply-To: References: <200606131901.k5DJ1LVs023416@canfield.cis.upenn.edu> <20060613221305.GA7396@petkovic.homeip.net> Message-ID: <20060614110455.GB19323@petkovic.homeip.net> On Tue, Jun 13, 2006 at 06:57:10PM -0400, Benjamin Pierce wrote: > > I'm going to try to compile the latest stable and beta on OpenBSD. > > If they work with lablgtk, would you be willing to roll this change > > back? > > Of course. I wasn't aware that it was working (and used) someplace. > The change can easily be undone. > I have just compiled successfully unison-2.13.16 (stable) and unison-2.17.1 (beta) on OpenBSD and submitted the port update to OpenBSD CVS committers. I also compiled a port of lablgtk2 but it segfaults when run. There's more work on this to follow, but for now I'm keeping unison with UISTYLE=gtk on OpenBSD. Please roll back the UISTYLE change in unison repository too. It seems that lablgtk1 is alive and kicking. :-) Best regards, Zvezdan Petkovic From mhopf at suse.de Wed Jun 14 11:22:42 2006 From: mhopf at suse.de (Matthias Hopf) Date: Wed, 14 Jun 2006 17:22:42 +0200 Subject: [Unison-hackers] unison stalling on low bandwidth lines with ssh Message-ID: <20060614152242.GB13577@suse.de> Hi all, I'm using unison-2.17.1 on Linux (SL10.1) with a couple of different setups. When using it over a relatively low-bandwidth DSL line via ssh over VPN, unison often stalls. Sometimes during startup, sometimes, during 'reconceiling changes', but most often at the beginning of or during transfer. I've read about stalls on the mailing list, but they were related to execution on Windows. I attached strace to both the remove server and the local client processes. While the server was hanging in a select() call, the client stayed in a select(), poll(), gettimeofday() (AFAIR) loop. Another ssh connection I was using e.g. for the strace is working fine, and ping requests are going through w/o problems. Even after tens of minutes of waiting, nothing changed. On the next startup behavior is typicall different, but similar, i.e. it stalls again, but at a differnt point of time. Is this a known bug, fixed in SVN, or could you need more testing? I can reproduce this pretty solidly, so if you can tell me what do to I would try to narrow this down. Thanks Matthias -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de From bcpierce at cis.upenn.edu Wed Jun 14 21:37:15 2006 From: bcpierce at cis.upenn.edu (bcpierce@cis.upenn.edu) Date: Wed, 14 Jun 2006 21:37:15 -0400 Subject: [Unison-hackers] [unison-svn] r165 - trunk/src Message-ID: <200606150137.k5F1bF4K009851@canfield.cis.upenn.edu> Author: bcpierce Date: 2006-06-14 21:37:15 -0400 (Wed, 14 Jun 2006) New Revision: 165 Modified: trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Restored UISTYLE=gtk build option and uigtk.ml module (which ARE apparently still very much used!) From alan.schmitt at polytechnique.org Thu Jun 22 08:14:32 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Thu, 22 Jun 2006 14:14:32 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? Message-ID: Hello, I'm wondering if Unison is copying over extended attributes (as described here for instance: http://arstechnica.com/reviews/os/ macosx-10.4.ars/7 ). It seems that rsync is able to copy them (using the -E flag), and cp and mv work as expected, but I do not see them being synchronized. I'm asking this because I've just started using Spotmeta (http:// www.fluffy.co.uk/spotmeta/index.html ) to tag files, and it relies on extended attributes. Thanks, Alan -- Alan Schmitt 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/20060622/ab9ce75d/PGP.pgp From alan.schmitt at polytechnique.org Thu Jun 22 08:18:21 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Thu, 22 Jun 2006 14:18:21 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: Message-ID: <4DB4611E-9AEF-4FEB-A681-30A78786BCA9@polytechnique.org> On 22 juin 06, at 14:14, Alan Schmitt wrote: > Hello, > > I'm wondering if Unison is copying over extended attributes (as > described here for instance: http://arstechnica.com/reviews/os/ > macosx-10.4.ars/7 ). It seems that rsync is able to copy them > (using the -E flag), and cp and mv work as expected, but I do not > see them being synchronized. As a followup I found some code on Apple's site to read, remove, and set these attributes: http://developer.apple.com/samplecode/filesystem_examples/listing3.html http://developer.apple.com/samplecode/filesystem_examples/listing4.html http://developer.apple.com/samplecode/filesystem_examples/listing5.html Alan -- Alan Schmitt 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/20060622/4701dd19/PGP.pgp From geoffw at cis.upenn.edu Thu Jun 22 18:58:19 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Thu, 22 Jun 2006 18:58:19 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: Message-ID: <449B208B.4080009@cis.upenn.edu> Alan Schmitt wrote: > I'm wondering if Unison is copying over extended attributes (as > described here for instance: > http://arstechnica.com/reviews/os/macosx-10.4.ars/7 ). It seems that > rsync is able to copy them (using the -E flag), and cp and mv work as > expected, but I do not see them being synchronized. I am pretty sure unison cannot synchronize extended attributes yet. rsync, mv, cp, etc. can handle extended attributes because Apple modified them in Tiger. I started some very preliminary work on an OCaml interface to the "C" extended attribute functions, but I really haven't had much time to focus on this project. If you want to help out, let me know. From geoffw at cis.upenn.edu Thu Jun 22 18:58:19 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Thu, 22 Jun 2006 18:58:19 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: Message-ID: <449B208B.4080009@cis.upenn.edu> Alan Schmitt wrote: > I'm wondering if Unison is copying over extended attributes (as > described here for instance: > http://arstechnica.com/reviews/os/macosx-10.4.ars/7 ). It seems that > rsync is able to copy them (using the -E flag), and cp and mv work as > expected, but I do not see them being synchronized. I am pretty sure unison cannot synchronize extended attributes yet. rsync, mv, cp, etc. can handle extended attributes because Apple modified them in Tiger. I started some very preliminary work on an OCaml interface to the "C" extended attribute functions, but I really haven't had much time to focus on this project. If you want to help out, let me know. From alan.schmitt at polytechnique.org Fri Jun 23 02:57:51 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 23 Jun 2006 08:57:51 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <449B208B.4080009@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> Message-ID: On 23 juin 06, at 00:58, Geoffrey Alan Washburn wrote: > Alan Schmitt wrote: > >> I'm wondering if Unison is copying over extended attributes (as >> described here for instance: >> http://arstechnica.com/reviews/os/macosx-10.4.ars/7 ). It seems that >> rsync is able to copy them (using the -E flag), and cp and mv work as >> expected, but I do not see them being synchronized. > > I am pretty sure unison cannot synchronize extended attributes yet. > rsync, mv, cp, etc. can handle extended attributes because Apple > modified them in Tiger. I started some very preliminary work on an > OCaml > interface to the "C" extended attribute functions, but I really > haven't > had much time to focus on this project. If you want to help out, > let me > know. Well, this is something I'd really like Unison to support. My main worry is not getting the attributes or reconciling changes to them, it's exposing them in the UI. Alan -- Alan Schmitt 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/20060623/1cc75173/PGP.pgp From bcpierce at cis.upenn.edu Fri Jun 23 09:25:43 2006 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Fri, 23 Jun 2006 09:25:43 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: <449B208B.4080009@cis.upenn.edu> Message-ID: <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> >> I am pretty sure unison cannot synchronize extended attributes yet. >> rsync, mv, cp, etc. can handle extended attributes because Apple >> modified them in Tiger. I started some very preliminary work on an >> OCaml >> interface to the "C" extended attribute functions, but I really >> haven't >> had much time to focus on this project. If you want to help out, >> let me >> know. > > Well, this is something I'd really like Unison to support. My main > worry is not getting the attributes or reconciling changes to them, > it's exposing them in the UI. This is something we've dealt with already for some somewhat similar cases -- e.g., the TYPE and CREATOR fields on OSX, which I believe are handled fairly cleanly, and resource forks, which we didn't succeed in handling at especially cleanly (the possible presence of resource forks pollutes a lot of code in a lot of modules). So there's a good and a bad precedent. :-) For the UI, I guess the main issue is how big the information is -- can it just go in the same place as the permission bits, or does it need to be summarized in some way? - Benjamin From geoffw at cis.upenn.edu Fri Jun 23 10:12:44 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Fri, 23 Jun 2006 10:12:44 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> Message-ID: <449BF6DC.6090300@cis.upenn.edu> Benjamin Pierce wrote: > This is something we've dealt with already for some somewhat similar > cases -- e.g., the TYPE and CREATOR fields on OSX, which I believe > are handled fairly cleanly, and resource forks, which we didn't > succeed in handling at especially cleanly (the possible presence of > resource forks pollutes a lot of code in a lot of modules). So > there's a good and a bad precedent. :-) Extended attributes are now used to implement resource forks (as of MacOS 10.4), and extended attributes are available on Linux and several other Unixes (for ACLs among other things) so it would probably make things a bit cleaner to remove the resource fork code and add extended attribute support. > For the UI, I guess the main issue is how big the information is -- > can it just go in the same place as the permission bits, or does it > need to be summarized in some way? I'm not aware of any limits on the size of the data an extended attribute can hold (other than perhaps size_t). Looking at the man pages, I can't see anything about a limit on the length of an attribute name. It is probably reasonable to assume they are less than 255 UTF8 characters. From geoffw at cis.upenn.edu Fri Jun 23 10:12:44 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Fri, 23 Jun 2006 10:12:44 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> Message-ID: <449BF6DC.6090300@cis.upenn.edu> Benjamin Pierce wrote: > This is something we've dealt with already for some somewhat similar > cases -- e.g., the TYPE and CREATOR fields on OSX, which I believe > are handled fairly cleanly, and resource forks, which we didn't > succeed in handling at especially cleanly (the possible presence of > resource forks pollutes a lot of code in a lot of modules). So > there's a good and a bad precedent. :-) Extended attributes are now used to implement resource forks (as of MacOS 10.4), and extended attributes are available on Linux and several other Unixes (for ACLs among other things) so it would probably make things a bit cleaner to remove the resource fork code and add extended attribute support. > For the UI, I guess the main issue is how big the information is -- > can it just go in the same place as the permission bits, or does it > need to be summarized in some way? I'm not aware of any limits on the size of the data an extended attribute can hold (other than perhaps size_t). Looking at the man pages, I can't see anything about a limit on the length of an attribute name. It is probably reasonable to assume they are less than 255 UTF8 characters. From geoffw at cis.upenn.edu Fri Jun 23 10:14:50 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Fri, 23 Jun 2006 10:14:50 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: <449B208B.4080009@cis.upenn.edu> Message-ID: <449BF75A.6040207@cis.upenn.edu> Alan Schmitt wrote: > Well, this is something I'd really like Unison to support. My main worry > is not getting the attributes or reconciling changes to them, No it isn't really a big deal, there just aren't OCaml stubs for the appropriate functions. Or at least there wasn't last time I checked. > it's exposing them in the UI. Okay, I don't really know much about how the GUI should behave. From geoffw at cis.upenn.edu Fri Jun 23 10:14:50 2006 From: geoffw at cis.upenn.edu (Geoffrey Alan Washburn) Date: Fri, 23 Jun 2006 10:14:50 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: References: <449B208B.4080009@cis.upenn.edu> Message-ID: <449BF75A.6040207@cis.upenn.edu> Alan Schmitt wrote: > Well, this is something I'd really like Unison to support. My main worry > is not getting the attributes or reconciling changes to them, No it isn't really a big deal, there just aren't OCaml stubs for the appropriate functions. Or at least there wasn't last time I checked. > it's exposing them in the UI. Okay, I don't really know much about how the GUI should behave. From alan.schmitt at polytechnique.org Fri Jun 23 12:14:01 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 23 Jun 2006 18:14:01 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> Message-ID: <103D166B-966B-41F5-86C0-CAA94B970339@polytechnique.org> On 23 juin 06, at 15:25, Benjamin Pierce wrote: > This is something we've dealt with already for some somewhat similar > cases -- e.g., the TYPE and CREATOR fields on OSX, which I believe > are handled fairly cleanly, and resource forks, which we didn't > succeed in handling at especially cleanly (the possible presence of > resource forks pollutes a lot of code in a lot of modules). So > there's a good and a bad precedent. :-) Interesting. > For the UI, I guess the main issue is how big the information is -- > can it just go in the same place as the permission bits, or does it > need to be summarized in some way? What if permission bits are changed in one direction, and file content in the other direction: is this a conflict? How does the UI may reflect this? The problem is that different extended attributes may be changed on both side, and I don't really see how to nicely present this yet. Alan -- Alan Schmitt 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/20060623/d40032db/PGP.pgp From alan.schmitt at polytechnique.org Fri Jun 23 12:24:03 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Fri, 23 Jun 2006 18:24:03 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <449BF6DC.6090300@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> <23D91CBC-33CD-48D0-80A8-9645817A0311@cis.upenn.edu> <449BF6DC.6090300@cis.upenn.edu> Message-ID: <60D69BB6-6788-4D8F-87BA-3B7A26F61188@polytechnique.org> On 23 juin 06, at 16:12, Geoffrey Alan Washburn wrote: > Extended attributes are now used to implement resource forks (as of > MacOS 10.4), and extended attributes are available on Linux and > several > other Unixes (for ACLs among other things) so it would probably make > things a bit cleaner to remove the resource fork code and add extended > attribute support. About the resource fork part, I'm not 100% sure. I think I read there is unified access through the xattr functions, but that the storage of resource forks is the same as before. > I'm not aware of any limits on the size of the data an extended > attribute can hold (other than perhaps size_t). Looking at the man > pages, I can't see anything about a limit on the length of an > attribute > name. It is probably reasonable to assume they are less than 255 UTF8 > characters. There is a recommendation not to have attributes bigger than 4KB, but it is not a hard limit it seems. Alan -- Alan Schmitt 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/20060623/8b405db6/PGP-0001.pgp From trevor at research.att.com Sat Jun 24 09:49:31 2006 From: trevor at research.att.com (Trevor Jim) Date: Sat, 24 Jun 2006 09:49:31 -0400 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <449BF75A.6040207@cis.upenn.edu> References: <449B208B.4080009@cis.upenn.edu> <449BF75A.6040207@cis.upenn.edu> Message-ID: <1DEABF0F-4266-4DAF-966E-02C3E9404F4F@research.att.com> One important detail not mentioned so far: cross-platform support. How do you sync a file with extended attributes on Mac to Windows or Linux? For forks, type, creator, there is an existing standard way of doing this that we have coopted. I don't know whether that supports all the attributes you want. (We are using Apple Double files.) Note that when Apple extended rsync etc. they did not deal with the problem of cross-platform sync. Others have had to work on that. Here is an article about metadata support for backup tools on OS X, it has some useful information: http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup-and- cloning-tools-under-mac-os-x/ Regarding the hooks into the OS functions to read attributes, etc., there are two difficulties. First, Apple has not necessarily done a good job documenting this stuff, in my experience. Second, these functions might exists in 10.4 but not in 10.3, so, there are issues similar to what happens for cross-platform support. My experience adding support for resource forks, etc., is that this is something that needs a lot of care. -Trevor From alan.schmitt at polytechnique.org Sat Jun 24 13:03:29 2006 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 24 Jun 2006 19:03:29 +0200 Subject: [Unison-hackers] Unison and extended attributes (xattr) on Tiger? In-Reply-To: <1DEABF0F-4266-4DAF-966E-02C3E9404F4F@research.att.com> References: <449B208B.4080009@cis.upenn.edu> <449BF75A.6040207@cis.upenn.edu> <1DEABF0F-4266-4DAF-966E-02C3E9404F4F@research.att.com> Message-ID: <47E8E27D-93AC-4556-A5DA-032616EDF93F@polytechnique.org> On 24 juin 06, at 15:49, Trevor Jim wrote: > One important detail not mentioned so far: cross-platform > support. How do you sync a file with extended attributes > on Mac to Windows or Linux? For forks, type, creator, > there is an existing standard way of doing this that we > have coopted. I don't know whether that supports all the > attributes you want. (We are using Apple Double files.) The same happens with extended attributes for "cp": for a file "file", they get stored in "._file". > Here is an article about metadata support for backup tools > on OS X, it has some useful information: > > http://blog.plasticsfuture.org/2006/03/05/the-state-of-backup- > and-cloning-tools-under-mac-os-x/ I've read this some time ago (and found it very interesting). I hope future versions of OS X will clean up a bit the mess that is metadata today. > Regarding the hooks into the OS functions to read attributes, > etc., there are two difficulties. First, Apple has not necessarily > done a good job documenting this stuff, in my experience. > Second, these functions might exists in 10.4 but not in 10.3, > so, there are issues similar to what happens for cross-platform > support. Yes, so synchronizing them should depend on a flag. > My experience adding support for resource forks, etc., is that > this is something that needs a lot of care. I agree, this is why I'm not sure of the way to go. But I find metadata more and more important, and I would really like to have a way to synchronize it. Alan -- Alan Schmitt 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/20060624/d30b8b0b/PGP.pgp From owigger at geo.unizh.ch Tue Jun 27 04:18:31 2006 From: owigger at geo.unizh.ch (Othmar Wigger) Date: Tue, 27 Jun 2006 10:18:31 +0200 Subject: [Unison-hackers] MacOSX Unison still crashing Message-ID: <44A0E9D7.6050203@geo.unizh.ch> Dear Unison-Hackers Despite the recent bug fix of May 25th, the MacOS X version of Unison still crashes. We can reliably reproduce this crash: 1. on a remote host, create a rather large file (1 GB) dd if=/dev/zero of=bigfile bs=1000000 count=1000 2. sync this with Unison 2.20.2 (SVN version compiled with ocaml 3.0.9.2) to a 300 MHz G3 Mac, running OS X 10.4.6, connected with fast ethernet 3. almost every time, Unison crashes after transferring about 500 MB In Library/Logs/CrashReporter, we find a crash report containing: Version: 2.20.2 (2.20.2) Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000403 Thread 0 Crashed: 0 edu.upenn.cis.Unison 0x0000cc54 camlUimacbridge__unisonRiToProgress_283 + 32 (UnisonToolbar.m:198) 1 edu.upenn.cis.Unison 0x0009481c caml_start_program + 280 (UnisonToolbar.m:198) ... The full crash report is at http://www.geo.unizh.ch/~pmarchi/crash/Unison.crash.log Are we right to believe that there is one more bug? Maybe more duplicated code? Cheers, Othmar ----------------------------------------------------------------------------- Dr. Othmar Wigger System Administrator Department of Geography Tel. +41 44 635 5888 University of Zurich Fax. +41 44 635 6848 CH-8057 Zuerich, Switzerland email: owigger at geo.unizh.ch ----------------------------------------------------------------------------- From bcpierce at cis.upenn.edu Wed Jun 28 00:23:37 2006 From: bcpierce at cis.upenn.edu (Benjamin Pierce) Date: Tue, 27 Jun 2006 23:23:37 -0500 Subject: [Unison-hackers] MacOSX Unison still crashing In-Reply-To: <44A0E9D7.6050203@geo.unizh.ch> References: <44A0E9D7.6050203@geo.unizh.ch> Message-ID: <885EC0F4-944C-4537-88C6-22EF7379B418@cis.upenn.edu> I'm guessing this is the same as the intermittent crash I'm seeing in the OSX GUI, which is believed to be related to a race condition in the GUI. (The text UI does not exhibit the problem for me, so using it is a workaround.) Regards, - Benjamin On Jun 27, 2006, at 3:18 AM, Othmar Wigger wrote: > Dear Unison-Hackers > > Despite the recent bug fix of May 25th, the MacOS X version of Unison > still crashes. > > We can reliably reproduce this crash: > > 1. on a remote host, create a rather large file (1 GB) > dd if=/dev/zero of=bigfile bs=1000000 count=1000 > > 2. sync this with Unison 2.20.2 (SVN version compiled with ocaml > 3.0.9.2) > to a 300 MHz G3 Mac, running OS X 10.4.6, connected with fast > ethernet > > 3. almost every time, Unison crashes after transferring about 500 MB > > In Library/Logs/CrashReporter, we find a crash report containing: > > Version: 2.20.2 (2.20.2) > Thread: 0 > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000403 > > Thread 0 Crashed: > 0 edu.upenn.cis.Unison 0x0000cc54 > camlUimacbridge__unisonRiToProgress_283 + 32 (UnisonToolbar.m:198) > 1 edu.upenn.cis.Unison 0x0009481c caml_start_program + 280 > (UnisonToolbar.m:198) > > ... > > The full crash report is at > http://www.geo.unizh.ch/~pmarchi/crash/Unison.crash.log > > Are we right to believe that there is one more bug? Maybe more > duplicated code? > > > Cheers, > Othmar > > ---------------------------------------------------------------------- > ------- > Dr. Othmar Wigger System Administrator > Department of Geography Tel. +41 44 635 5888 > University of Zurich Fax. +41 44 635 6848 > CH-8057 Zuerich, Switzerland email: owigger at geo.unizh.ch > ---------------------------------------------------------------------- > ------- > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From tsunamithecat at mac.com Wed Jun 28 00:46:45 2006 From: tsunamithecat at mac.com (Matthew Alford) Date: Tue, 27 Jun 2006 21:46:45 -0700 Subject: [Unison-hackers] latest osx build In-Reply-To: <885EC0F4-944C-4537-88C6-22EF7379B418@cis.upenn.edu> References: <44A0E9D7.6050203@geo.unizh.ch> <885EC0F4-944C-4537-88C6-22EF7379B418@cis.upenn.edu> Message-ID: <5E9B0326-D138-4E4C-9C35-38EA626A0F8F@mac.com> Sorry all, I have been away for a couple months and am trying to pick up the thread of the latest build for OSX. I recall some discussion about maintaining a binary - did this ever happen? Or could someone send me the latest binary? If not I will use svn and build it myself but I need to use my other machine that has ocaml... blah blah... Thanks, Matthew On Jun 27, 2006, at 9:23 PM, Benjamin Pierce wrote: > I'm guessing this is the same as the intermittent crash I'm seeing in > the OSX GUI, which is believed to be related to a race condition in > the GUI. (The text UI does not exhibit the problem for me, so using > it is a workaround.) > > Regards, > > - Benjamin > > > On Jun 27, 2006, at 3:18 AM, Othmar Wigger wrote: > >> Dear Unison-Hackers >> >> Despite the recent bug fix of May 25th, the MacOS X version of Unison >> still crashes. >> >> We can reliably reproduce this crash: >> >> 1. on a remote host, create a rather large file (1 GB) >> dd if=/dev/zero of=bigfile bs=1000000 count=1000 >> >> 2. sync this with Unison 2.20.2 (SVN version compiled with ocaml >> 3.0.9.2) >> to a 300 MHz G3 Mac, running OS X 10.4.6, connected with fast >> ethernet >> >> 3. almost every time, Unison crashes after transferring about 500 MB >> >> In Library/Logs/CrashReporter, we find a crash report containing: >> >> Version: 2.20.2 (2.20.2) >> Thread: 0 >> Exception: EXC_BAD_ACCESS (0x0001) >> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000403 >> >> Thread 0 Crashed: >> 0 edu.upenn.cis.Unison 0x0000cc54 >> camlUimacbridge__unisonRiToProgress_283 + 32 (UnisonToolbar.m:198) >> 1 edu.upenn.cis.Unison 0x0009481c caml_start_program + 280 >> (UnisonToolbar.m:198) >> >> ... >> >> The full crash report is at >> http://www.geo.unizh.ch/~pmarchi/crash/Unison.crash.log >> >> Are we right to believe that there is one more bug? Maybe more >> duplicated code? >> >> >> Cheers, >> Othmar >> >> --------------------------------------------------------------------- >> - >> ------- >> Dr. Othmar Wigger System Administrator >> Department of Geography Tel. +41 44 635 5888 >> University of Zurich Fax. +41 44 635 6848 >> CH-8057 Zuerich, Switzerland email: owigger at geo.unizh.ch >> --------------------------------------------------------------------- >> - >> ------- >> >> _______________________________________________ >> Unison-hackers mailing list >> Unison-hackers at lists.seas.upenn.edu >> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From pmarchi at geo.unizh.ch Wed Jun 28 02:13:10 2006 From: pmarchi at geo.unizh.ch (Patrick Marchi) Date: Wed, 28 Jun 2006 08:13:10 +0200 Subject: [Unison-hackers] latest osx build In-Reply-To: <5E9B0326-D138-4E4C-9C35-38EA626A0F8F@mac.com> References: <44A0E9D7.6050203@geo.unizh.ch> <885EC0F4-944C-4537-88C6-22EF7379B418@cis.upenn.edu> <5E9B0326-D138-4E4C-9C35-38EA626A0F8F@mac.com> Message-ID: <44A21DF6.2080408@geo.unizh.ch> Hi Matthew > Sorry all, > I have been away for a couple months and am trying to pick up the > thread of the latest build for OSX. I recall some discussion about > maintaining a binary - did this ever happen? Or could someone send > me the latest binary? You can find an allmost latest binary at http://www.geo.unizh.ch/~pmarchi/unison/mac/unison-2.20.2.tar.gz for OSX. Patrick ----------------------------------------------------------- Patrick Marchi IT staff Department of Geography Tel +41 44 635 65 33 University of Zurich Fax +41 44 635 68 48 Winterthurerstrasse 190 pmarchi at geo.unizh.ch CH-8057 Zurich, Switzerland http://www.geo.unizh.ch ----------------------------------------------------------- From tsunamithecat at mac.com Wed Jun 28 12:36:42 2006 From: tsunamithecat at mac.com (Matthew Alford) Date: Wed, 28 Jun 2006 09:36:42 -0700 Subject: [Unison-hackers] latest osx build In-Reply-To: <44A21DF6.2080408@geo.unizh.ch> References: <44A0E9D7.6050203@geo.unizh.ch> <885EC0F4-944C-4537-88C6-22EF7379B418@cis.upenn.edu> <5E9B0326-D138-4E4C-9C35-38EA626A0F8F@mac.com> <44A21DF6.2080408@geo.unizh.ch> Message-ID: <4D71E80E-0271-449D-8F7D-9AFD4663D381@mac.com> Thanks a lot. -M On Jun 27, 2006, at 11:13 PM, Patrick Marchi wrote: > Hi Matthew >> Sorry all, >> I have been away for a couple months and am trying to pick up the >> thread of the latest build for OSX. I recall some discussion about >> maintaining a binary - did this ever happen? Or could someone send >> me the latest binary? > You can find an allmost latest binary at > http://www.geo.unizh.ch/~pmarchi/unison/mac/unison-2.20.2.tar.gz > for OSX. > > Patrick > > ----------------------------------------------------------- > Patrick Marchi IT staff > Department of Geography Tel +41 44 635 65 33 > University of Zurich Fax +41 44 635 68 48 > Winterthurerstrasse 190 pmarchi at geo.unizh.ch > CH-8057 Zurich, Switzerland http://www.geo.unizh.ch > ----------------------------------------------------------- > > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers