summaryrefslogtreecommitdiff
path: root/Assistant
Commit message (Collapse)AuthorAge
* belt and suspenders checkGravatar Joey Hess2012-06-20
| | | | | | It's possible for there to be multiple queued changes all adding the same file, and for those changes to be reordered. Maybe. This check will guard against that ending up adding the wrong version of the file last.
* 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.)
* maintain set of files pendingAddGravatar Joey Hess2012-06-20
| | | | | | | | Kqueue needs to remember which files failed to be added due to being open, and retry them. This commit gets the data in place for such a retry thread. Broke KeySource out into its own file, and added Eq and Ord instances so it can be stored in a Set.
* inverted logicGravatar Joey Hess2012-06-19
|
* fix kevent symlink creationGravatar Joey Hess2012-06-19
|
* make --force really bypass lsof checkGravatar 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.
* check files with lsof in batches before addingGravatar Joey Hess2012-06-15
| | | | | I've tested both cases where this is necessary, and it works great! A file with multiple writers is not added until the last one closes.
* race avoidanceGravatar Joey Hess2012-06-15
| | | | When there are duplicate add events for the same file, only add it once.
* can't wait for LinkChanges specificallyGravatar Joey Hess2012-06-15
| | | | | | | | There is indeed a race waiting for LinkChanges: 1. file annexed, link made 2. link deleted 3. inotify event for link creation runs, but as link is gone, handler is not run
* continued work on deferred adddingGravatar Joey Hess2012-06-15
|
* 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.
* catch IO exceptions in runThreadStateGravatar Joey Hess2012-06-15
| | | | | | | | | A few places catch IO errors after calling runThreadState, but since the MVar was not restored, it'd later deadlock trying to read from it. I'd like to catch all exceptions here, but I could not get the types to unify.
* check for unstaged old symlinks in the sanity checkerGravatar Joey Hess2012-06-13
|
* add sanity checker threadGravatar Joey Hess2012-06-13
| | | | Currently wakes up once a day, and does nothing. :)
* tweakGravatar Joey Hess2012-06-13
|
* finish daemon status threadGravatar Joey Hess2012-06-13
|
* 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