<div dir="ltr"><div dir="ltr">This matches my (somewhat hazy :-) recollection. <br><br>       - Benjamin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 5, 2021 at 3:16 PM Tõivo Leedjärv <<a href="mailto:toivol@gmail.com">toivol@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The "watch" preference defaulting to "true" has caused some issues<br>
([1] [2] and some others) to users who may not even know they are<br>
running with the watcher enabled. With some of these bugs unresolved<br>
and watcher semantics still somewhat confusing and limited (see<br>
below), I'd like to initiate a discussion to make "watch" preference<br>
default to "false". This default can then be revised again once<br>
critical bugs are fixed and semantics extended or better documented.<br>
<br>
The exact proposal is this:<br>
1. "watch = false" becomes the default for everyone.<br>
2. "watch" is automatically flipped to "true" if "-repeat watch" is specified.<br>
<br>
Reasoning for point 2 is simple: "-repeat watch" requires "watch =<br>
true" and specifying "repeat" is the only request the user should make<br>
or be forced to know about.<br>
<br>
Reasoning for point 1 can now completely exclude scenarios where the<br>
user has specified "-repeat watch". It is my assumption that using<br>
"watch = true" without "-repeat watch" is currently almost always a<br>
result of the defaults, not of user intention. There is no clear<br>
documentation of the "watch" preference for users to base their<br>
intentions on.<br>
<br>
I have investigated the code a bit and my current (possibly limited or<br>
incorrect) understanding is that a) the "watch" preference without<br>
"-repeat watch" is only leveraged by the GUIs; and b) the effect of<br>
the "watch = true" without "-repeat watch" is limited to non-existent.<br>
Users (in general, but even more so when using the text UI) are not<br>
getting any benefits from the default preference, yet they are exposed<br>
to potential bugs.<br>
<br>
The limited to non-existent effect claim is based on my understanding<br>
that input from the fsmonitor process is used solely to filter the<br>
(static) list of paths Unison is going to scan. The list of paths to<br>
scan itself does not come from fsmonitor process, it is the list of<br>
paths from the profile. For example, if the user has not specified any<br>
explicit paths then the paths to scan are the roots. Here, the effect<br>
from "watch = true" is binary, either not scan the root (no changes<br>
reported by fsmonitor) or scan the entire root (any change reported by<br>
fsmonitor). This may sound like somewhat of a benefit but it has to be<br>
put in context: first, it currently works only in GUIs (for example by<br>
clicking the "Rescan" button; but not when specifying "-repeat N" on<br>
command line), and second, re-scanning even big roots tends to be very<br>
(even extremely) fast (assuming much has been cached). It may be<br>
slower on Windows (I have no empirical data) but again, the decision<br>
not to scan is made only if fsmonitor has not reported any changes at<br>
all.<br>
<br>
Please do correct me if my understanding is incorrect at any point.<br>
<br>
At the moment, the fsmonitor binary is not packaged on Windows due to [2].<br>
<br>
[1] <a href="https://github.com/bcpierce00/unison/issues/329#issuecomment-708633505" rel="noreferrer" target="_blank">https://github.com/bcpierce00/unison/issues/329#issuecomment-708633505</a><br>
[2] <a href="https://github.com/bcpierce00/unison/pull/493#issuecomment-823419018" rel="noreferrer" target="_blank">https://github.com/bcpierce00/unison/pull/493#issuecomment-823419018</a><br>
_______________________________________________<br>
Unison-hackers mailing list<br>
<a href="mailto:Unison-hackers@LISTS.SEAS.UPENN.EDU" target="_blank">Unison-hackers@LISTS.SEAS.UPENN.EDU</a><br>
<a href="https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers" rel="noreferrer" target="_blank">https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers</a><br>
</blockquote></div>