| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
| |
Move lsof check, and display a message before daemon startup if on an
unsupported OS.
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
When there are duplicate add events for the same file, only add it once.
|
| |
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Currently wakes up once a day, and does nothing. :)
|
| | |
|
| | |
|
| |
|
|
|
| |
Also afterLastDaemonRun, with 10 minute slop to handle majority of clock
skew issues.
|
| |
|
Joey Hess