Polling vs. File System Watch

Nice job on the interface and usability for this project. Looks very promising. Are there plans to move from a polling style to a file system watch type system? e.g. on Linux there is inotify (AFAIK Mac OSX and Windows have their own native file system watch daemons).

Today I use lsyncd (based on inotify and rsync) and it works great with some drawbacks.

  • Complicated to setup
  • Only compatible with Linux
  • Is two-way sync challenged

If only there was an abstraction layer that allowed a single code base (like Syncthing) to work with different OS’s and their native file system watch daemons. On larger file systems (more and more common in the consumer space) the 60 second polling re-scan system may not be efficient enough.

ok, off my soapbox… =)

1 Like

Like this? https://github.com/Zillode/syncthing-inotify

And thats the main reason why it’s still polling, every system has different watch daemons.

The discusion for that on github:

and as @jpjp pointed out a version with inotify is in work

right, thanks jpjp and l33tname for the references. i didn’t see those previously. i guess the key would be to create an abstraction layer (think database abstraction layers) but for different os file system watch daemons. anyway, if someone was to say “that’s way too hard and beyond the scope of this project” it would be very hard for me to refute. great stuff either way.

p.s. just got done reading the github thread, a lot of interesting options, was a good read.

Exactly, if someone has the time to write a go abstraction library for that I’m sure @calmh will include this.