From bcpierce at cis.upenn.edu Mon Jan 25 15:27:04 2016 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Mon, 25 Jan 2016 15:27:04 -0500 Subject: [Unison-hackers] Discrepancy in fswatch.ml and fsmonitor.py In-Reply-To: <5684D2CB.5010308@stankevitz.com> References: <5684D2CB.5010308@stankevitz.com> Message-ID: <2E6CC486-1092-49F2-ABA1-D17B329D89E9@cis.upenn.edu> OK, after a little detective work, I think I understand? :-) There are currently two file-watching modules in Unison: fswatchold.ml, the older one (surprisingly enough), calls fsmonitor.py fswatch.ml, the newer one, seems to work only on Linux and Windows; it calls unison-fsmonitor, which is an OCaml program (found in the fsmonitor subdirectory) that is built separately from Unison. They use a somewhat fancier protocol to communicate. If you look around the rest of the code, you?ll see calls to both modules. But calls to Fswatchold functions are forwarded to Fswatch if the newer monitor is running. So you?re correct that fsmonitor.py is not the right place to start for you. You probably want to clone fsmonitor/linux and go from there. Best, - Benjamin > On Dec 31, 2015, at 2:01 AM, Chris Stankevitz wrote: > > Can someone explain this discrepancy in the 2.48.3 source distribution: > > 1. fswatch.ml describes (and implements) a notification protocol in which stdin/stdout is used to communicate messages such as VERSION, OK, DIR, LINK, CHANGE, etc > > 2. fsmonitor.py implements a notification protocol but it does not send or receive any of the commands in (1). Furthermore it does not send commands to stdout, rather it writes them to a file called "changes" in a way that does not agree with (1). > > What I was expecting to see: > > 3. fswatch.ml describe a protocol > > 4. fsmonitor.py implements the protocol in (3) > > The reason I am asking: I would like to add freebsd support to the fsmonitor process.... but I am not confident that fsmonitor.py is the correct starting place. > > Thank you, > > Chris > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcpierce at seas.upenn.edu Wed Jan 27 11:29:50 2016 From: bcpierce at seas.upenn.edu (bcpierce at seas.upenn.edu) Date: Wed, 27 Jan 2016 11:29:50 -0500 Subject: [Unison-hackers] [unison-svn] r553 - trunk/src Message-ID: <201601271629.u0RGTolh030918@yaws.seas.upenn.edu> Author: bcpierce Date: 2016-01-27 11:29:50 -0500 (Wed, 27 Jan 2016) New Revision: 553 Modified: trunk/src/Makefile trunk/src/RECENTNEWS trunk/src/mkProjectInfo.ml Log: * Make the installation Makefile a bit more paranoid, to prevent bad behavior if the OCaml installation is not present or messed up Modified: trunk/src/Makefile =================================================================== --- trunk/src/Makefile 2015-12-08 14:10:15 UTC (rev 552) +++ trunk/src/Makefile 2016-01-27 16:29:50 UTC (rev 553) @@ -90,6 +90,10 @@ $(MAKE) -C .. text doinstall: $(NAME)$(EXEC_EXT) + if [ ! $(NAME) ]; then \ + echo "makefile variable NAME not bound"; \ + exit 1 \ + ; fi -mv $(INSTALLDIR)/$(NAME)$(EXEC_EXT) /tmp/$(NAME)-$(shell echo $$$$) cp $(NAME)$(EXEC_EXT) $(INSTALLDIR) cp $(NAME)$(EXEC_EXT) $(INSTALLDIR)$(NAME)-$(MAJORVERSION)$(EXEC_EXT) Modified: trunk/src/RECENTNEWS =================================================================== --- trunk/src/RECENTNEWS 2015-12-08 14:10:15 UTC (rev 552) +++ trunk/src/RECENTNEWS 2016-01-27 16:29:50 UTC (rev 553) @@ -1,3 +1,8 @@ +CHANGES FROM VERSION 2.49.9 + +* Make the installation Makefile a bit more paranoid, to prevent bad + behavior if the OCaml installation is not present or messed up +------------------------------- CHANGES FROM VERSION 2.49.8 * Update copyright dates to 2016 Modified: trunk/src/mkProjectInfo.ml =================================================================== --- trunk/src/mkProjectInfo.ml 2015-12-08 14:10:15 UTC (rev 552) +++ trunk/src/mkProjectInfo.ml 2016-01-27 16:29:50 UTC (rev 553) @@ -110,3 +110,4 @@ + From alan.schmitt at polytechnique.org Sat Jan 30 09:29:52 2016 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 30 Jan 2016 15:29:52 +0100 Subject: [Unison-hackers] backup bug with backuplocation being only a directory? Message-ID: Hello, I?m setting up some unison backups and I think I have stumbled upon a bug. The problem is when the backupprefix preference is a directory: after the backup directory is created, it is proposed to be synchronized for the following sync. Here is a detailed example: With this profile --8<---------------cut here---------------start------------->8--- root = /Users/schmitta/tmp/unison_test/a root = /Users/schmitta/tmp/unison_test/b backup = Name * backuplocation = local backupprefix = .unisonbak/ backupsuffix = .$VERSION --8<---------------cut here---------------end--------------->8--- If I do the following (I assume a and b are created and empty): % unison testbak Contacting server... Looking for changes Reconciling changes Nothing to do: replicas have not changed since last sync. % touch a/foo % unison testbak -batch Contacting server... Looking for changes Reconciling changes new file ----> foo a : new file modified on 2016-01-30 at 15:22:39 size 0 rw-r--r-- b : absent Propagating updates UNISON 2.48.3 started propagating changes at 15:22:52.16 on 30 Jan 2016 [BGN] Copying foo from /Users/schmitta/tmp/unison_test/a to /Users/schmitta/tmp/unison_test/b [END] Copying foo UNISON 2.48.3 finished propagating changes at 15:22:52.16 on 30 Jan 2016 Saving synchronizer state Synchronization complete at 15:22:52 (1 item transferred, 0 skipped, 0 failed) % ls -al a b a: total 0 drwxr-xr-x+ 3 schmitta staff 102 Jan 30 15:22 . drwxr-xr-x+ 4 schmitta staff 136 Jan 30 15:21 .. -rw-r--r--+ 1 schmitta staff 0 Jan 30 15:22 foo b: total 0 drwxr-xr-x+ 3 schmitta staff 102 Jan 30 15:22 . drwxr-xr-x+ 4 schmitta staff 136 Jan 30 15:21 .. -rw-r--r--+ 1 schmitta staff 0 Jan 30 15:22 foo % echo hello > a/foo; unison testbak -batch Contacting server... Looking for changes Reconciling changes changed ----> foo a : changed file modified on 2016-01-30 at 15:23:49 size 6 rw-r--r-- b : unchanged file modified on 2016-01-30 at 15:22:39 size 0 rw-r--r-- Propagating updates UNISON 2.48.3 started propagating changes at 15:23:50.46 on 30 Jan 2016 [BGN] Updating file foo from /Users/schmitta/tmp/unison_test/a to /Users/schmitta/tmp/unison_test/b [END] Updating file foo UNISON 2.48.3 finished propagating changes at 15:23:50.46 on 30 Jan 2016 Saving synchronizer state Synchronization complete at 15:23:50 (1 item transferred, 0 skipped, 0 failed) % ls -al a b a: total 8 drwxr-xr-x+ 3 schmitta staff 102 Jan 30 15:22 . drwxr-xr-x+ 4 schmitta staff 136 Jan 30 15:21 .. -rw-r--r--+ 1 schmitta staff 6 Jan 30 15:23 foo b: total 8 drwxr-xr-x+ 4 schmitta staff 136 Jan 30 15:23 . drwxr-xr-x+ 4 schmitta staff 136 Jan 30 15:21 .. drwxr-xr-x+ 3 schmitta staff 102 Jan 30 15:23 .unisonbak -rw-r--r--+ 1 schmitta staff 6 Jan 30 15:23 foo # until here all is as expected, but ? % unison testbak Contacting server... Looking for changes Reconciling changes a b <---- new dir .unisonbak [f] Note that the bug does not happen if the prefix is more than a directory, for instance: backupprefix = .unisonbak/bak__ Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 Athmospheric CO? (Updated January 29, 2016, Mauna Loa Obs.): 402.60 ppm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From alan.schmitt at polytechnique.org Sat Jan 30 09:45:52 2016 From: alan.schmitt at polytechnique.org (Alan Schmitt) Date: Sat, 30 Jan 2016 15:45:52 +0100 Subject: [Unison-hackers] backup documentation typo Message-ID: Hello, The documentation for backups says ?By default, backup files are named .bak.VERSION.FILENAME, where FILENAME is the original filename and VERSION is the backup number (1 for the most recent, 2 for the next most recent, etc.).? As I?m testing it seems that VERSION starts at 0 and not 1. Is this correct? Thanks, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 Athmospheric CO? (Updated January 29, 2016, Mauna Loa Obs.): 402.60 ppm -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: