The first thing in the .stignore is “.ssh”. Syncthing does not have permissions to read it. It has to be this way.
Syncthing issues a “File Watch Error” in a big orange box for “.ssh” So Syncthing ignores the ignore file. There is much discussion on this fact in these forums, so this is not a surprise. In my opinion it is a bug, but it is not a surprise.
However, in the folder dialog, under in the section “Rescans” it issues the error “Failed to setup, retrying”. There are no other errors issued.
When I hit the ‘rescan’ button it does nothing.
The folder itself says “Up To Date”
I would ask the question as to how to get it to ignore the .ssh directory when scanning, but I gather that this is currently impossible. Ignore apparently does not affect scanning.
My question now is do I believe it? Apart from ‘.ssh’ is it really “Up To Date” or has it refused to scan and thus is missing things?
If you have negative patterns (!foo) it needs to look into .ssh, because there might be matches under there. Or at least it thinks it needs to, even if we as humans might know better. Not being able to access that directory it can’t set up the fs watcher. Nonetheless the periodic scan will pick up all the things that it can access.
There are no exceptions (negative patterns) to files in the .ssh folder. It is ignored in its entirety. Furthermore it is the first pattern in the .stignore, which appears to be top down scanned for matches. (If it is not scanned top down, please elaborate as to how it is scanned. Thanks.)
That sounds like you do have include pattern, just not matching .ssh. That doesn’t matter, the watcher still needs to scan the entire tree and thus fails on .ssh.
What we could do though is when an error occurs, check if the corresponding path is matched by a non-negated ignore pattern and in that case, just squelch the error message.
Sorry I don’t understand what you’re saying and how it relates to my proposal. Could you please elaborate?
What I meant was roughly, during scanning (pseudocode):
err = scan(path)
if err == PermissionDenied or err == IOError:
foreach pattern in ignore:
if pattern.matches(path) and !pattern.isNegated():
return
logError(err)
If path is a file, there can be no children, so no other patterns need to be checked. If it is a directory and not accessible, we can’t access the children either, so any negated pattern applicable below this path doesn’t matter.
Unless there are directories which fail to scan, but descendants of it could still succeed?
The error is for the filesystem watcher. in the scanner we do what you describe. but the watcher aborts entirely if encountering an error, so we mustn’t suppress the error just because an ignored path caused it.
On at least some OSes the watching API is internally recursive, that is we ask to watch a top level and we get everything below – or we don’t, if there are access problems. This is also what our API looks like which is sometimes emulated onto other lower level concepts, as I remember it.
Certainly it would be possible to do a scan, find all the various top level branches we can access, set up watches for just those and report errors for other branches, etc.
But none of this should affect the OP, but since they just speak in generalities and sarcasms we don’t know much about their actual setup.