| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This is more efficient. Note that the peer will get CHANGED messages for
all refs changed since the connection opened, even if those changes
happened before it sent NOTIFYCHANGE.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added to change notification to P2P protocol.
Switched to a TBChan so that a single long-running thread can be
started, and serve perhaps intermittent requests for change
notifications, without buffering all changes in memory.
The P2P runner currently starts up a new thread each times it waits
for a change, but that should allow later reusing a thread. Although
each connection from a peer will still need a new watcher thread to run.
The dependency on stm-chans is more or less free; some stuff in yesod
uses it, so it was already indirectly pulled in when building with the
webapp.
This commit was sponsored by Francois Marier on Patreon.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I'm unsure why this fixed it, but it did. Seems to suggest that the
memory leak is not due to a bug in my code, but that ghc didn't manage
to take full advantage of laziness, or was failing to gc something it
could have.
|
| |
|
|
|
|
| |
So we get some useful error messages when things fail.
This commit was sponsored by Peter Hogg on Patreon.
|
| | |
|
| |
|
|
| |
AppendMode does not allow seeking..
|
| |
|
|
|
| |
WriteMode zeros any existing content, so the seek filled with zeros, and
verification failed after download.
|
| | |
|
| |
|
|
|
|
|
|
| |
This is needed in addition to StoreContent, because retrieveKeyFile can
be used to retrieve to different destination files, not only the tmp
file for a key.
This commit was sponsored by Ole-Morten Duesund on Patreon.
|
| |
|
|
|
|
|
|
|
|
| |
ReadContent can't update the log, since it reads lazily. This part of
the P2P monad will need to be rethought.
Associated files are heavily sanitized when received from a peer;
they could be an exploit vector.
This commit was sponsored by Jochen Bartl on Patreon.
|
| |
|
|
| |
This will allow updating transfer logs with the uuid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Untested, and it does not yet update transfer logs.
Verifying transferred content is modeled on git-annex-shell recvkey.
In a direct mode or annex.thin repository, content can change while it's
being transferred. So, verification is always done, even if annex.verify
would normally prevent it.
Note that a WORM or URL key could change in a way the verification
doesn't catch. That can happen in git-annex-shell recvkey too. We don't
worry about it, because those key backends don't guarantee preservation
of data. (Which is to say, I worried about it, and then convinced myself
again it was ok.)
|
|
|
Each worker thread needs to run in the Annex monad, but the
remote-daemon's liftAnnex can only run 1 action at a time. Used
Annex.Concurrent to deal with that.
P2P.Annex is incomplete as of yet.
|
Joey Hess