I installed syncthing with homebrew on OSX 10.14 and have it running as a service. Everything works fine except for changes to files are not detected until a full rescan occurs.
It is pretty much the same issue as described here: Mac FS Watcher
I can see that the aggregator starts when I run st with STTRACE=watchaggregator,scanner, but upon changing a file nothing happens.
I tried reinstalling syncthing, but the issue persists. The file watcher seems to work fine on the Android app.
Is it enabled? Does Syncthing complain about it not being able to watch for changes? Does it work with our release binaries from Github instead of homebrew?
It’s enabled and I don’t see any complaints in the logs, just this message: ‘DEBUG: aggregator/“Notes” (6scsh-x95pt): No tracked events, waiting for new event.’
I tried the latest binary from the GitHub releases and get the same behavior.
Okay. File watcher works for me on macOS, with our binaries, so I think we’ll need more info. Config or screenshots, what sort of filesystem maybe, things like that.
Okay, let me know if there’s more info that could be useful:
Binary info: syncthing v1.1.1-rc.1 "Erbium Earthworm" (go1.12 darwin-amd64) teamcity@build.syncthing.net 2019-03-12 12:59:26 UTC
And here is the filesystem info for the drive where the ‘Notes’ folder is located:
Device Identifier: disk1s1
Device Node: /dev/disk1s1
Whole: No
Part of Whole: disk1
Volume Name: Macintosh HD
Mounted: Yes
Mount Point: /
Partition Type: 41504653-0000-11AA-AA11-00306543ECAC
File System Personality: APFS
Type (Bundle): apfs
Name (User Visible): APFS
Owners: Enabled
OS Can Be Installed: Yes
Booter Disk: disk1s2
Recovery Disk: disk1s3
Media Type: Generic
Protocol: PCI-Express
SMART Status: Not Supported
Volume UUID: DB9B8268-8ED8-3C5C-A29B-0CE7CAC37C90
Disk / Partition UUID: DB9B8268-8ED8-3C5C-A29B-0CE7CAC37C90
Disk Size: 500.0 GB (499963174912 Bytes) (exactly 976490576 512-Byte-Units)
Device Block Size: 4096 Bytes
Volume Total Space: 500.0 GB (499963174912 Bytes) (exactly 976490576 512-Byte-Units)
Volume Used Space: 377.2 GB (377159614464 Bytes) (exactly 736639872 512-Byte-Units) (75.4%)
Volume Free Space: 122.8 GB (122803560448 Bytes) (exactly 239850704 512-Byte-Units) (24.6%)
Allocation Block Size: 4096 Bytes
Read-Only Media: No
Read-Only Volume: No
Device Location: Internal
Removable Media: Fixed
Solid State: Yes
Hardware AES Support: NoI think I’ve found the issue. The folder was called ‘notes’ on the file system, but syncthing was looking for ‘Notes’. That should probably be case-insensitive, but renaming the folder to ‘Notes’ makes the file watcher work.
The problem here is OS X filesystem is only partly case-sensitive, while there are truly case-sensitive filesystems where this Syncthing behaviour makes perfect sense. Since Syncthing is generally aiming to support as wide a range of OSes as possible, this is the way it goes as of now. Adding a check to make sure the filesystem in question is half-case-sensitive (as opposed to totally-case-insensitive FAT or NTFS and case-sensitive EXT or ZFS) is not trivial and quite some work (if at all possible).
That makes sense. It is odd that a manual rescan works fine, but just the file watcher doesn’t work. I guess maybe the scanner uses a different method of finding the folder.
Yeah… I think the issue here is that Syncthing is watching /Users/foo/Notes/... but then gets told about a change in /Users/foo/notes/... which it doesn’t see as being under the watched path. We resolve this at least on Windows by figuring out the actual filesystem name for the folder, but maybe that doesn’t work on macOS.
Case (in)sensitivity in general is a swamp. 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.