| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
Both when queueing downloads, and uploads, consults the preferred content
settings.
I didn't make it check yet when requeing failed transfers or queuing
deferred downloads; dealing with the preferred content settings (or indeed,
other settings) changing while the assistant is running still needs work.
|
| |
|
|
| |
And add a form to add another, unrelated repository
|
| |
|
|
| |
Just an optimisation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now when a download is queued and there's no known remote to get it from,
it's added to a deferred download list, which will be retried later.
The Merger thread tries to queue any deferred downloads when it receives
a push to the git-annex branch.
Note that the Merger thread now also forces an update of the git-annex
branch. The assistant was not updating this branch before, and it saw a
(mostly) correct view of state, but now that incoming pushes go to
synced/git-annex, it needs to be merged in.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The code to maintain that TChan in parallel with the list was buggy,
the two were not always the same. And all that TChan was needed for was
blocking on the next transfer, which can be accomplished just as well by
checking the size and retrying, thanks to STM.
Also, this is faster, and uses less memory. Total win.
|
| |
|
|
|
|
| |
When multiple downloads of a key are queued, it starts the first, but leaves the
other downloads in the queue. This ensures that we don't lose a queued
download if the one that got started failed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Currently only the web special remote is readonly, but it'd be possible to
also have readonly drives, or other remotes. These are handled in the
assistant by only downloading from them, and never trying to upload to
them.
|
| |
|
|
| |
of a remote
|
| |
|
|
|
|
| |
A paused transfer's thread keeps running, keeping the slot in use.
This is intentional; pausing a transfer should not let other
queued transfers to run in its place.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Should work (untested) for transfers being run by other processes.
Not yet by transfers being run by the assistant. killThread does not
kill processes forked off by a thread. To fix this, will probably
need to make `git annex getkey` and `git annex sendkey` commands that
operate on keys, and write their own transfer info. Then the assistant
can run them, and kill them, as needed.
|
| |
|
|
|
|
|
| |
Putting the transfer on the currentTransfers atomically introduced a bug:
It checks to see if the transfer is in progress, and cancels it.
Fixed by moving that check inside the STM transaction.
|
| | |
|
| |
|
|
|
|
| |
The fun part was making it move things from TransferQueue to currentTransfers
entirely atomically. Which will avoid inconsistent display if the WebApp
renders the current status at just the wrong time. STM to the rescue!
|
| |
|
|
|
|
| |
I've convinced myself that nothing in DaemonStatus can deadlock,
as it always keepts the TMVar full. That was the only reason it was in the
Annex monad.
|
| |
|
|
| |
yowza!!!
|
| |
|
|
| |
Now scanning runs fully interleaved with transferring.
|
| | |
|
| |
|
|
|
|
|
| |
Allow transfers to be added with blocking until the queue is sufficiently
small.
Better control over which end of the queue to add a transfer to.
|
| |
|
|
|
| |
Efficiently finding transfers that need to be done to get two repos back
in sync seems like an interesting problem.
|
| |
|
|
|
|
| |
This should fix OSX/BSD issues with not noticing transfer information
files with kqueue. Now that threads are used, the thread can manage the
transfer slot allocation and deallocation by itself; much cleaner.
|
| |
|
|
|
| |
Also converted its timestand to posix seconds, like is used in the other
log files.
|
| | |
|
| |
|
|
|
|
| |
There's still a bug; if the child updates its transfer info file,
then the data from it will superscede the TransferInfo, losing the
info that we should wait on this child.
|
| | |
|
| |
|
|
| |
finally!
|
| | |
|
| |
|
|
|
|
|
| |
Added knownRemotes to DaemonStatus. This list is not entirely trivial to
calculate, and having it here should make it easier to add/remove remotes
on the fly later on. It did require plumbing the daemonstatus through to
some more threads.
|
| |
|
Joey Hess