| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
That'll fail when building offline.
|
| | |
|
| | |
|
| |
|
|
|
| |
This library should be easier to install than ADNS, so I've made it
be used by default.
|
| |
|
|
|
|
|
| |
a key's presence.
Also, use the new withQuietOutput function to avoid running the shell to
/dev/null stderr in two other places.
|
| | |
|
| |\
| |
| |
| |
| | |
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.
|
| | | |
|
| |/
|
|
|
|
| |
I had been using -ignore-package monads-tf to deal with this, but
the XMPP library uses monads-tf, so that also ignores it. Instead,
use PackageImports to force use of mtl in my own code.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
debian/changelog
git-annex.cabal
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
rsync
When rsyncProgress pipes rsync's stdout, this turns out to cause a ssh
process started by rsync to be left behind as a zombie. I don't know why,
but my recent zombie reaping cleanup was correct, it's just that this other
zombie, that's not directly started by git-annex, was no longer reaped
due to changes in the cleanup. Make rsyncProgress reap the zombie started
by rsync, as a workaround.
FWIW, the process tree looks like this. It seems like the rsync child
is for some reason starting but not waiting on this extra ssh process.
Ssh connection caching may be involved -- disabling it seemed to change
the shape of the tree, but did not eliminate the zombie.
9378 pts/14 S+ 0:00 | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ...
9379 pts/14 S+ 0:00 | | \_ ssh ...
9380 pts/14 S+ 0:00 | | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ...
9381 pts/14 Z+ 0:00 | \_ [ssh] <defunct>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Interesting type signature ghc derived for this:
forall o (m :: * -> *). Monad m => Matcher o -> (o -> m Bool) -> m Bool
|
| | |
| |
| |
| |
| |
| |
| | |
utf8.
The crash actually occurred when writing out the file, which was done to a
handle that had not had fileSystemEncoding applied to it.
|
| | |
| |
| |
| | |
TMI when full env is passed in and modified..
|
| | |
| |
| |
| |
| | |
On the cabal side, let's just require this new version, and set -DURI_24
to enable the code using it.
|
| | | |
|
| | |\
| |/
|/|
| |
| | |
Conflicts:
debian/changelog
|
| | | |
|
| |/
|
|
| |
SampleVars from base are unsafe
|
| |
|
|
|
|
| |
Nearly everything that's reading from git is operating on a small
amount of output and has been switched to use that. Only pipeNullSplit
stuff continues using the lazy version that yields zombies.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes a full parser for the boolean expressions in the log,
that compiles them into Matchers. Those matchers are not used yet.
A complication is that matching against an expression should never
crash git-annex with an error. Instead, vicfg checks that the expressions
parse. If a bad expression (or an expression understood by some future
git-annex version) gets into the log, it'll be ignored.
Most of the code in Limit couldn't fail anyway, but I did have to make
limitCopies check its parameter first, and return an error if it's bad,
rather than erroring at runtime.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This seems to fix a problem I've recently seen where ctrl-c during rsync
leads to `git annex get` moving on to the next thing rather than exiting.
Seems likely that started happening with the switch to System.Process
(d1da9cf221aeea5c7ac8a313a18b559791a04f12), as the old code took care
to install a default SIGINT handler.
Note that since the bug was only occurring sometimes, I am not 100% sure
I've squashed it, although I seem to have.
|
| | |
|
| |
|
|
|
| |
It already applied the pruner when traversing directories, so .git is
excluded, but .gitignore was not. Now it is.
|
| |
|
|
|
|
| |
This is a workaround for bind failing with EINVAL sometimes on OSX.
I don't know why; EVINAL should mean the socket is already bound to an
address, but this is with a new socket.
|
| | |
|
| |
|
|
|
| |
Really the fix here is to make Utility.Process only throw IOErrors,
which is what I naturally assumed it'd throw.
|
| |
|
|
| |
specified amount of time.
|
| |
|
|
|
|
|
|
|
|
|
| |
Simplified it using existing functions.
I doubt setSticky needs to return the FileMode; if it does for some
reason, it can be changed to use modifyFileMode'
Converted isSticky to a pure function for consistency with isSymlink.
Note that the sticky bit of a file can be tested thus:
isSticky . fileMode <$> getFileStatus file
|
| |
|
|
| |
Finally done with progressbars!
|
| |
|
|
|
| |
Does rsync stall and update its progress display? Dunno, but this was an
easy optimisation to throw in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is handled differently for inotify, which can track modifications of
existing files, and kqueue, which cannot (TTBOMK). On the inotify side,
the TransferWatcher just waits for the file to be updated and reads the new
bytesComplete. On the kqueue side, the TransferPoller has to re-read the
file every update (currently 0.5 seconds, might need to increase that).
I did think about working around kqueue's limitations by somehow creating
a new file each time the size changed. But cleaning up all the files that
would result seemed difficult. And really, this is not a lot worse than
the TransferWatcher's behavior for downloads, which stats a file every 0.5
seconds. As long as the OS has decent file caching behavior..
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Current implementation parses rsync's output a character a time, which
is hardly efficient. It could be sped up a lot by using hGetBufSome,
but that would require going really lowlevel, down to raw C style buffers
(good example of that here: http://users.aber.ac.uk/afc/stricthaskell.html)
But rsync doesn't output very much, so currently it seems ok.
|
| | |
|
Joey Hess
Ben Gamari
Joey Hess