summaryrefslogtreecommitdiff
path: root/Assistant/Watcher.hs
Commit message (Collapse)AuthorAge
* pending adds now retried for kqueueGravatar Joey Hess2012-06-20
| | | | | | | | | | | | | | | | Rethought how to keep track of pending adds that need to be retried later. The commit thread already run up every second when there are changes, so let's keep pending adds queued as changes until they're safe to add. Also, the committer is now smarter about avoiding empty commits when all the adds are currently unsafe, or in the rare case that an add event for a symlink is not received in time. It may avoid them entirely. This seems to work as before for inotify, and is untested for kqueue. (Actually commit batching seems to be improved for inotify, although I'm not sure why. I'm seeing only two commits made during large batch operations, and the first of those is the non-batch mode commit.)
* fix kevent symlink creationGravatar Joey Hess2012-06-19
|
* lifted out the kqueue and inotify to a generic DirWatcher interfaceGravatar Joey Hess2012-06-18
| | | | | Kqueue code for dispatching events is not tested and probably doesn't build.
* refactorGravatar Joey Hess2012-06-19
|
* fix buildGravatar Joey Hess2012-06-19
|
* kqueue code compiles on debian kfreebsdGravatar Joey Hess2012-06-18
|
* recurse dirTree and open the directories for kqueue to watchGravatar Joey Hess2012-06-18
|
* skeleton C library for calling kqueueGravatar Joey Hess2012-06-18
|
* make inotify a build flag etcGravatar Joey Hess2012-06-17
|
* startup check fixesGravatar Joey Hess2012-06-17
| | | | | Move lsof check, and display a message before daemon startup if on an unsupported OS.
* preliminary deferring of file adds to commit timeGravatar Joey Hess2012-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | Defer adding files to the annex until commit time, when during a batch operation, a bundle of files will be available. This will allow for checking a them all with a single lsof call. The tricky part is that adding the file causes a symlink change inotify. So I made it wait for an appropriate number of symlink changes to be received before continuing with the commit. This avoids any delay in the commit process. It is possible that some unrelated symlink change is made; if that happens it'll commit it and delay committing the newly added symlink for 1 second. This seems ok. I do rely on the expected symlink change event always being received, but only when the add succeeds. Another way to do it might be to directly stage the symlink, and then ignore the redundant symlink change event. That would involve some redundant work, and perhaps an empty commit, but if this code turns out to have some bug, that'd be the best way to avoid it. FWIW, this change seems to, as a bonus, have produced better grouping of batch changes into single commits. Before, a large batch change would result in a series of commits, with the first containing only one file, and each of the rest bundling a number of files. Now, the added wait for the symlink changes to arrive gives time for additional add changes to be processed, all within the same commit.
* implement daemon status serialization to a fileGravatar Joey Hess2012-06-13
| | | | | Also afterLastDaemonRun, with 10 minute slop to handle majority of clock skew issues.
* reorganizeGravatar Joey Hess2012-06-13