| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
The just created repo has no master branch commits yet. This is now
handled, merging in the master branch from the populated drive.
|
| |
|
|
| |
branch yet
|
| |\
| |
| |
| |
| | |
Conflicts:
Init.hs
|
| | | |
|
| | |
| |
| |
| | |
remote setup still todo
|
| | |
| |
| |
| |
| |
| |
| |
| | |
git annex assistant --autostart will start separate daemons in each
listed autostart repo
running the webapp outside any git-annex repo will open it on the
first listed autostart repo
|
| | |
| |
| |
| | |
Remove --foreground and --stop options from it.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This prevents multiple runs of the assistant in the foreground, and lets
--stop stop foregrounded runs too.
The webapp firstrun case also now writes a pid file, once it's made the git
repo to put it in.
|
| | |
| |
| |
| | |
Some of the trickiest code I've possibly ever written.
|
| | |
| |
| |
| | |
My $HOME is in git, let's make it work :)
|
| | |
| |
| |
| |
| | |
Maybe later it can prompt if they want to use the repo with git-annex, but
for now this is a sane easy choice.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
config is valid.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This avoids forking another process, avoids polling, fixes a race,
and avoids a rare forkProcess thread hang that I saw once time
when starting the webapp.
|
| | |
| |
| |
| | |
I've seen 10 be too short under load.
|
| | |
| |
| |
| |
| |
| | |
the pid file
fixes a possible race
|
| | | |
|
| | |
| |
| |
| | |
--force could enable other, unwanted behavior
|
| | |
| |
| |
| | |
Useful for testing..
|
| | | |
|
| | |
| |
| |
| | |
Also, starts the assistant if it wasn't already running.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make Utility.Process wrap the parts of System.Process that I use,
and add debug logging to them.
Also wrote some higher-level code that allows running an action
with handles to a processes stdin or stdout (or both), and checking
its exit status, all in a single function call.
As a bonus, the debug logging now indicates whether the process
is being run to read from it, feed it data, chat with it (writing and
reading), or just call it for its side effect.
|
| | |
| |
| |
| | |
New log file format.
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Test suite now passes with -threaded!
I traced back all the hangs with -threaded to System.Cmd.Utils. It seems
it's just crappy/unsafe/outdated, and should not be used. System.Process
seems to be the cool new thing, so converted all the code to use it
instead.
In the process, --debug stopped printing commands it runs. I may try to
bring that back later.
Note that even SafeSystem was switched to use System.Process. Since that
was a modified version of code from System.Cmd.Utils, it needed to be
converted too. I also got rid of nearly all calls to forkProcess,
and all calls to executeFile, which I'm also doubtful about working
well with -threaded.
|
| |\| |
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
finally!
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This *almost* works.
Along the way, I noticed that the --uuid parameter was being accidentially
passed after the --, so that has never been actually used by
git-annex-shell to verify it's running in the expected repository. Oops. Fixed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Not yet tested and places git-annex-shell is run need to be modified to
pass the new field settings.
Note that rsyncServerSend was changed to fork, rather than directly exec
rsync, because it needs to keep the transfer lock held, and clean up the
transfer log when done.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to record a semi-useful filename associated with the key,
this required plumbing the filename all the way through to the remotes'
storeKey and retrieveKeyFile.
Note that there is potential for deadlock here, narrowly avoided.
Suppose the repos are A and B. A sends file foo to B, and at the same
time, B gets file foo from A. So, A locks its upload transfer info file,
and then locks B's download transfer info file. At the same time,
B is taking the two locks in the opposite order. This is only not a
deadlock because the lock code does not wait, and aborts. So one of A or
B's transfers will be aborted and the other transfer will continue.
Whew!
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
is already in progress by another process.
Note this is per-remote, so trying to get the same file from multiple
remotes can still let duplicate downloads run. (And uploading the same file
to multiple remotes is not duplicate at all of course.)
get, move, and copy are the only git-annex subcommands that transfer
files, but there's still git-annex-shell recvkey and sendkey to deal with too.
I considered modifying retrieveKeyFile or getViaTmp, but they are called
by other code that does not involve expensive file transfers (migrate)
or that does file transfers that should not be checked by this (fsck --from).
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
While this word may be less familiar to some users, it avoids the
connotation that version 2 is better than version 1, which is wrong
when the two variants were conflicting.
|
| | | |
|
| | |
| |
| |
| | |
this is necessary so the sync can continue successfully with its push phase
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
untested, but it compiles :)
|
| | | |
|
| |\| |
|
Joey Hess