| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
If it managed to run for 5 minutes, reconnect immediately. Otherwise,
wait 5 minutes before reconnecting.
|
| |
|
|
|
|
|
|
| |
Adjust build deps to ensure that only a fixed version of the library will
be used.
Also, removed the bound thread stuff, which I now think was (probably)
a red herring.
|
| |\
| |
| |
| |
| | |
Conflicts:
Assistant/Threads/NetWatcher.hs
|
| | |
| |
| |
| |
| |
| |
| |
| | |
MountWatcher can't do this, because it uses the session dbus,
and won't have access to the new DBUS_SESSION_BUS_ADDRESS if a new session
is started.
Bumped dbus library version, FD leak in it is fixed.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Currently relies on SRV being set, or the JID's hostname being the server
hostname and the port being default. Future work: Allow manual
configuration of user name, hostname, and port.
|
| | | |
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
Assistant/Threads/MountWatcher.hs
Assistant/Threads/NetWatcher.hs
|
| | |
| |
| |
| |
| |
| |
| | |
Now when the dbus connection is dropped, it'll fall back to polling.
I could make it try to reconnect, but there's a FD leak in the dbus
library, so not yet.
|
| | |
| |
| |
| | |
which doesn't work with LDAP or NIS.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This *may* solve the segfault I was seeing when the XMPP library called
startTLS. My hypothesis is as follows:
* TLS is documented
(http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety)
thread safe, but only when a single thread accesses it.
* forkIO threads are not bound to an OS thread, so it was possible for
the threaded runtime to run part of the XMPP code on one thread, and
then switch to another thread later.
So, forkOS, with its bound threads, should be used for the XMPP thread.
Since the crash doesn't happen reliably, I am not yet sure about this fix.
Note that I kept all the other threads in the assistant unbound, because
bound threads have significantly higher overhead.
|
| | |
| |
| |
| |
| | |
When pushing to multiple UUIDs, combine them all into a single push
attribute.
|
| | |
| |
| |
| | |
Push notifications are actually working over XMPP now!
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems presence notifications are not sent to clients that have marked
themselves unavailable. (Testing with google talk.)
This is the death knell for the presence hack, because it has to stay
available, and even the toggle to unavailable and back could cause it to
miss a notification. Still, flipped it so it basically works, for now.
|
| | |
| |
| |
| |
| | |
Still need to do something about transfer queueing, however. This could be
a real can of worms.
|
| | |
| |
| |
| |
| |
| |
| | |
Lacking error handling, reconnection, credentials configuration,
and doesn't actually do anything when it receives an incoming notification.
Other than that, it might work! :)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Hooked up everything that needs to notify on pushes. Note that
syncNewRemote does not notify. This is probably ok, and I'd need to thread
more state through to make it do so.
This is only set up to support a single push notification method; I didn't
use a NotificationBroadcaster. Partly because I don't yet know what info
about pushes needs to be communicated, so my data types are only
preliminary.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Monitors git-annex branch for changes, which are noticed by the Merger
thread whenever the branch ref is changed (either due to an incoming push,
or a local change), and refreshes cached config values for modified config
files.
Rate limited to run no more often than once per minute. This is important
because frequent git-annex branch changes happen when files are being
added, or transferred, etc.
A primary use case is that, when preferred content changes are made,
and get pushed to remotes, the remotes start honoring those settings.
Other use cases include propigating repository description and trust
changes to remotes, and learning when a remote has added a new special
remote, so the webapp can present the GUI to enable that special remote
locally.
Also added a uuid.log cache. All other config files already had caches.
|
| |
|
|
| |
Yay, monadic Either!
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
debian/changelog
git-annex.cabal
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This can result in the file being dropped, or being downloaded, or even
being dropped from some other repo.
It's even possible to create a file in a directory where content is not
wanted, which will make the assistant immediately send it elsewhere, and
then drop it.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This was complicated quite a bit by needing to check numcopies. I optimised
that, so it only looks up numcopies once per file, no matter how many
remotes it checks to drop from. Although it did just occur to me that
it might be better to first check if it wants to drop content, and only
then check numcopies..
|
| | |
| |
| |
| | |
Also a small optimisation using a Set
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
get list of remotes after, rather than before, a potentially blocking action
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids the expensive transfer scan relying on its list of remotes
to scan being accurate throughout, which it will not be when the user
pauses syncing to a remote.
I feel it's ok to queue transfers to *any* known remote, not just the ones
being scanned.
Note that there are still small races where after syncing to a remote is
paused, a transfer can be queued for it. Not just in the expensive transfer
scan, but in the cheap failed transfer scan, and elsewhere.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This reserves annex.ignore for repos that should not be visible at all;
repos with syncing disabled are now skipped by the assistant, but are
displayed in the list and can be configured.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I noticed this while offline (so that lack of solar power is good for something).
Apparently it tries to bind multicast to lo, and that fails.
If this happens, catch it, and retry until a real network interface becomes
available.
It may be that this should tie into the NetWatcher, and rebind whenever
an interface comes up. Needs testing..
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
webapp: Adds newly created repositories to one of these groups:
clients, drives, servers
This is heuristic, but it's a pretty good heuristic, and can always be
configured.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
Joey Hess
Nicolas Pouillard