From frederik at ofb.net Tue Aug 18 16:44:08 2015 From: frederik at ofb.net (Frederik Eaton) Date: Tue, 18 Aug 2015 13:44:08 -0700 Subject: [Unison-hackers] list of unison issues / todo list Message-ID: <20150818204408.GD3723@ofb.net> Hello Unison Hackers, I've been using Unison successfully in spite of the path.ml bug (which perhaps only affects single-file roots?). It mostly works fine for me, but I figured that it might be useful for me to make a list of minor problems that I run into, in case someone decides to continue with Unison development. I'm attaching my list to this message and also made a 'gist' on github.com as an experiment: https://gist.github.com/70dfb7ff01d86fd8f300 I'm not sure how helpful that "gist" URL is... Also, I'm not sure how helpful it is to make a TODO list, I hope it encourages rather than discourages further work on Unison. Anyway, perhaps if somebody with write access to Unison could indicate agreement with some or all of the items on the list, then that would be a first step to getting them worked on. Thank you! Frederick P.S. I wrote this without first reading TODO.txt in the Unison tarball: https://webdav.seas.upenn.edu/viewvc/unison/trunk/src/TODO.txt?revision=506&view=markup but I don't see any of the issues I've identified in there... -------------- next part -------------- Unison TODO list ================ Here is a personal list of bugs and feature requests for the Unison file synchronizer. These issues refer to the text-based user interface (which is the one I use). At the time of this writing (18 August 2015) the latest Unison version is 2.48.3. To my knowledge, Unison is the most standard and straightforward file synchronizer for Linux. Many people say they now use 'git' or some other revision control software for situations where they would have used "Unison" in the past, but I still find Unison to be preferable for many tasks. In many cases, such as sharing configuration files between systems, I am not interested in storing an annotated revision history of changes I make. Using revision control to deal with conflicts in my own files seems cumbersome. A file synchronizer like Unison solves the problem with less hassle. While reacquainting myself with Unison recently, I made a list of problems that I ran into. It would be great if someone has time to fix them! ### Path.ml bug ### * For certain command-line options, such as 'backup' or 'merge', running unison on two single-file roots triggers an exception failure in 'path.ml'. Reported here in 2009: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517240 and here in 2015: http://lists.seas.upenn.edu/pipermail/unison-hackers/2015-July/001849.html According to my testing, this seems to affect Unison versions all the way from 2001! However, the bug could also have been caused by more recent changes in the O'Caml string library, we're not sure. ### Skipping and quitting ### * The help text for 'g' (currently: "proceed immediately to propagating changes") should make it clear that this will propagate _all future recommended_ changes, rather than just the ones that the user has already approved. The first few years I used Unison, I thought that 'g' meant "I've approved changes to a number of paths already, now I want to save my place by propagating just the changes I entered, skipping the rest of the paths". Instead it seems to mean "I want to propagate the changes I approved, as well as approving and propagating all the changes that Unison is about to recommend to me" - in other words "switch to batch mode now" - which seems less useful. Because the user doesn't control the order in which conflicts are presented, I don't see the value of being able to switch from interactive to batch mode mid-sync. This is a UI bug, but it could result in data loss in certain situations by triggering unintended "batch" syncs which propagate changes in the wrong direction. It potentially affects not only beginning users, but also experienced users who have read the entire documentation, since it's not documented. * Related to the above, there should be an option to "skip" all remaining paths, for users who are satisfied with the changes they've authorized so far and want save their work by propagating these changes before continuing. Perhaps this should be what 'g' actually does. * There should be an option (or default) to ask for confirmation when the user presses 'q' for 'quit', especially if changes have been authorized. Sometimes I accidentally press 'q' and lose some work, which is annoying. For instance, the results of 'diff' are usually displayed to me in a pager, but sometimes there is no pager (e.g. if I run unison with sudo). If I press 'q' out of habit to exit a non-existent pager, it instead exits Unison. If I press 'q' twice by accident, it exits Unison. * The help list starts out with three "ignore permanently" commands, which I think makes it easy to miss the fact that there is an option to essentially "ignore the path temporarily" down at the bottom ("skip"). I would move the 'skip' option nearer to this group, perhaps before it, in the Commands: help list, and perhaps rename to 'skip this path' for consistency with other command descriptions. * Typing 'p' for 'previous' doesn't work after 'I' for 'ignore permanently'. ### Paths ### * The 'root alias' option would be more useful if I didn't have to specify every possible "root" under a given directory or host. For instance, if I'm aliasing //hostB// to //hostA//, I think that should by default map //hostA/root1/ to //hostB/root1/ as well, since the prefix matches. In the current version of Unison I need a separate 'rootalias' option for subdirectories. This could be annoying if, for example, I have several roots on a host and I want to change the hostname. * In diff output, it would be nice to be able to provide more informative file names. Instead of this: ``` --- /home/frederik/.Xdefaults.unison.diff- 2015-07-30 17:17:20.353393267 -0700 +++ /home/frederik/.Xdefaults 2015-07-30 17:17:12.363370611 -0700 ``` we could be looking at ``` --- //host1//home/frederik/.Xdefaults 2015-07-30 17:17:20.353393267 -0700 +++ //host2//home/frederik/.Xdefaults 2015-07-30 17:17:12.363370611 -0700 ``` The GNU diff lets us specify these header path strings with the "--label=" option. To allow us to make use of this feature, Unison would need to give us the pretty path names in variables (e.g. HOSTPATH1 and HOSTPATH2) for substitution in the 'diff =' configuration option. Also see: https://wiki.archlinux.org/index.php/Unison#More_helpful_diff_output This is a suggestion for making Unison's 'diff' output more readable, which could be mentioned in the manual or turned into a default. * When a new file has been created in one root, 'd' for 'diff' should display the contents of the file (e.g. by diffing against /dev/null). * It's strange that "ignore = " allows pattern matching, but "path = " does not. What if I want to use Unison to merge every dot file in my home directory? The inability to use patterns to define groups of files makes it difficult. I guess this is a very basic design decision which would be difficult to change, but I noticed it has been brought up before on the mailing list. As far as I can tell from the documentation, 'ignorenot' does not serve as a workaround. * If I accidentally put a pattern instead of a literal path into a "path = " specification, the GUI gives me an error ("Filesystem watcher error"), but the text-based interface doesn't even give a warning. A warning would be nice. ### General interface ### * When I first start Unison, I see hostnames written above two columns. The columns may contain text like "changed" or "new file". However, if I press 'd', or '?', or 'l', or if I simply go through a lot of paths, I lose the host names header, and then I get '>' and '<' confused. It would be convenient if various commands which produce lots of output would finish by printing the column headers again as a reminder. * I tried to use 'merge = ' to specify a merge command which runs in the terminal, but this didn't work. Instead I had to make the command open an xterm with my merge program running inside it. It would be nice for Unison to give the 'merge' command access to the terminal. This would provide a simpler interface, and make debugging the merge command easier. Of course, GUI users would have to provide a different merge command. From bcpierce at cis.upenn.edu Tue Aug 18 19:49:09 2015 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Tue, 18 Aug 2015 19:49:09 -0400 Subject: [Unison-hackers] list of unison issues / todo list In-Reply-To: <20150818204408.GD3723@ofb.net> References: <20150818204408.GD3723@ofb.net> Message-ID: <76C803FA-9202-47C4-8D84-D3F5F7B4A07C@cis.upenn.edu> > Anyway, perhaps if somebody with > write access to Unison could indicate agreement with some or all of > the items on the list, then that would be a first step to getting them > worked on. Yes, these all seem like worthwhile improvements. If someone wants to implement them, I?ll be happy to consider patches. Best, - Benjamin > > Hello Unison Hackers, > > I've been using Unison successfully in spite of the path.ml bug (which > perhaps only affects single-file roots?). It mostly works fine for me, > but I figured that it might be useful for me to make a list of minor > problems that I run into, in case someone decides to continue with > Unison development. I'm attaching my list to this message and also > made a 'gist' on github.com as an experiment: > > https://gist.github.com/70dfb7ff01d86fd8f300 > > I'm not sure how helpful that "gist" URL is... Also, I'm not sure how > helpful it is to make a TODO list, I hope it encourages rather than > discourages further work on Unison. Anyway, perhaps if somebody with > write access to Unison could indicate agreement with some or all of > the items on the list, then that would be a first step to getting them > worked on. > > Thank you! > > Frederick > > P.S. I wrote this without first reading TODO.txt in the Unison > tarball: > > https://webdav.seas.upenn.edu/viewvc/unison/trunk/src/TODO.txt?revision=506&view=markup > > but I don't see any of the issues I've identified in there... > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From frederik at ofb.net Wed Aug 19 02:00:26 2015 From: frederik at ofb.net (Frederik Eaton) Date: Tue, 18 Aug 2015 23:00:26 -0700 Subject: [Unison-hackers] list of unison issues / todo list In-Reply-To: <76C803FA-9202-47C4-8D84-D3F5F7B4A07C@cis.upenn.edu> References: <20150818204408.GD3723@ofb.net> <76C803FA-9202-47C4-8D84-D3F5F7B4A07C@cis.upenn.edu> Message-ID: <20150819060025.GE3723@ofb.net> Thanks, that's good to hear. On Tue, Aug 18, 2015 at 07:49:09PM -0400, Benjamin C. Pierce wrote: > > Anyway, perhaps if somebody with > > write access to Unison could indicate agreement with some or all of > > the items on the list, then that would be a first step to getting them > > worked on. > > Yes, these all seem like worthwhile improvements. If someone wants to implement them, I?ll be happy to consider patches. > > Best, > > - Benjamin > > > > > > > Hello Unison Hackers, > > > > I've been using Unison successfully in spite of the path.ml bug (which > > perhaps only affects single-file roots?). It mostly works fine for me, > > but I figured that it might be useful for me to make a list of minor > > problems that I run into, in case someone decides to continue with > > Unison development. I'm attaching my list to this message and also > > made a 'gist' on github.com as an experiment: > > > > https://gist.github.com/70dfb7ff01d86fd8f300 > > > > I'm not sure how helpful that "gist" URL is... Also, I'm not sure how > > helpful it is to make a TODO list, I hope it encourages rather than > > discourages further work on Unison. Anyway, perhaps if somebody with > > write access to Unison could indicate agreement with some or all of > > the items on the list, then that would be a first step to getting them > > worked on. > > > > Thank you! > > > > Frederick > > > > P.S. I wrote this without first reading TODO.txt in the Unison > > tarball: > > > > https://webdav.seas.upenn.edu/viewvc/unison/trunk/src/TODO.txt?revision=506&view=markup > > > > but I don't see any of the issues I've identified in there... > > _______________________________________________ > > 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 chris at stankevitz.com Fri Aug 21 12:41:11 2015 From: chris at stankevitz.com (Chris Stankevitz) Date: Fri, 21 Aug 2015 09:41:11 -0700 Subject: [Unison-hackers] File watcher process for BSD Message-ID: <55D754A7.6000801@stankevitz.com> Hi, Is there a "file watcher process" (FWP) for FreeBSD? If not, I volunteer to make one using kqueue. Does unison only ask the FWP to monitor directories? If so, then I think kqueue's kern.maxfiles limit will not be an issue. On my system kern.maxfiles is ~2 million. When using '-repeat watch', how does unison discover the PID of the FWP? Or, if unison launches the FWP, how does unison learn the FWP's name? Thank you, Chris From matt at matthewlmcclure.com Fri Aug 21 13:38:28 2015 From: matt at matthewlmcclure.com (Matt McClure) Date: Fri, 21 Aug 2015 13:38:28 -0400 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: <55D754A7.6000801@stankevitz.com> References: <55D754A7.6000801@stankevitz.com> Message-ID: Is fsmonitor.py sufficient? On Fri, Aug 21, 2015 at 12:41 PM, Chris Stankevitz wrote: > Hi, > > Is there a "file watcher process" (FWP) for FreeBSD? If not, I volunteer > to make one using kqueue. > > Does unison only ask the FWP to monitor directories? If so, then I think > kqueue's kern.maxfiles limit will not be an issue. On my system > kern.maxfiles is ~2 million. > > When using '-repeat watch', how does unison discover the PID of the FWP? > Or, if unison launches the FWP, how does unison learn the FWP's name? > > Thank you, > > Chris > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers > -- http://matthewlmcclure.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at stankevitz.com Mon Aug 24 19:36:57 2015 From: chris at stankevitz.com (Chris Stankevitz) Date: Mon, 24 Aug 2015 16:36:57 -0700 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: References: <55D754A7.6000801@stankevitz.com> Message-ID: <55DBAA99.7060803@stankevitz.com> On 8/21/15 10:38 AM, Matt McClure wrote: > Is fsmonitor.py sufficient? Matt, I assumed it wasn't given that is has sections for linux, mac, and windows but not BSD. Mac code uses fsevents which is not supported on BSD. Linux code uses inotify which is not supported by BSD. Can you tell me: when using '-repeat watch', how does unison discover the PID of the fsmonitor.py? Or, if unison launches fsmonitor.py, where/how does it find it or where can I change the name? Thank you, Chris From matt at matthewlmcclure.com Wed Aug 26 07:34:34 2015 From: matt at matthewlmcclure.com (Matt McClure) Date: Wed, 26 Aug 2015 07:34:34 -0400 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: <55DBAA99.7060803@stankevitz.com> References: <55D754A7.6000801@stankevitz.com> <55DBAA99.7060803@stankevitz.com> Message-ID: > On Aug 24, 2015, at 19:36, Chris Stankevitz wrote: > > > >> On 8/21/15 10:38 AM, Matt McClure wrote: >> Is fsmonitor.py sufficient? > > Matt, > > I assumed it wasn't given that is has sections for linux, mac, and windows but not BSD. Mac code uses fsevents which is not supported on BSD. Linux code uses inotify which is not supported by BSD. You might know better then et than I do in that case. > Can you tell me: when using '-repeat watch', how does unison discover the PID of the fsmonitor.py? Or, if unison launches fsmonitor.py, where/how does it find it or where can I change the name? Sorry, I don't know without reading the code. > > Thank you, > > Chris > _______________________________________________ > 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 Wed Aug 26 15:26:26 2015 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Wed, 26 Aug 2015 15:26:26 -0400 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: References: <55D754A7.6000801@stankevitz.com> <55DBAA99.7060803@stankevitz.com> Message-ID: <2038E4DE-3D8B-4177-A8A7-045DBE78F61C@cis.upenn.edu> > >> Can you tell me: when using '-repeat watch', how does unison discover the PID of the fsmonitor.py? Or, if unison launches fsmonitor.py, where/how does it find it or where can I change the name? The place to look for this is in the current Unison sources is fswatch.ml for low-level communication with the watcher process and uitext.ml for high-level control. - B > > Sorry, I don't know without reading the code. > >> >> Thank you, >> >> Chris >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at stankevitz.com Thu Aug 27 12:21:37 2015 From: chris at stankevitz.com (Chris Stankevitz) Date: Thu, 27 Aug 2015 09:21:37 -0700 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: <55D754A7.6000801@stankevitz.com> References: <55D754A7.6000801@stankevitz.com> Message-ID: <55DF3911.5040201@stankevitz.com> On 8/21/15 9:41 AM, Chris Stankevitz wrote: > When using '-repeat watch', how does unison discover the PID of the FWP? > Or, if unison launches the FWP, how does unison learn the FWP's name? I think I found the answer in NEWS: "Unison will now look for fsmonitor.py in the same directory where the Unison executable itself lives." So it appears that the file watcher process must be named "fsmonitor.py" and it must live in the same directory as the unison binary. Chris From matt at matthewlmcclure.com Thu Aug 27 14:39:53 2015 From: matt at matthewlmcclure.com (Matt McClure) Date: Thu, 27 Aug 2015 14:39:53 -0400 Subject: [Unison-hackers] File watcher process for BSD In-Reply-To: <55DF3911.5040201@stankevitz.com> References: <55D754A7.6000801@stankevitz.com> <55DF3911.5040201@stankevitz.com> Message-ID: That matches my experience. -- http://matthewlmcclure.com/ http://cens.io/ > On Aug 27, 2015, at 12:21, Chris Stankevitz wrote: > >> On 8/21/15 9:41 AM, Chris Stankevitz wrote: >> When using '-repeat watch', how does unison discover the PID of the FWP? >> Or, if unison launches the FWP, how does unison learn the FWP's name? > > I think I found the answer in NEWS: "Unison will now look for fsmonitor.py in the same directory where the Unison executable itself lives." > > So it appears that the file watcher process must be named "fsmonitor.py" and it must live in the same directory as the unison binary. > > Chris > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers