| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
with annex.tune.objecthash1=true
Need to walk 1 level of subdirs less in this case.
The git-annex branch traversal code didn't have a similar bug.
|
| |
|
|
| |
copy of a file as one of the necessary copies to allow removing it from the import location.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes a bit of complexity, and should make things faster
(avoids tokenizing Params string), and probably involve less garbage
collection.
In a few places, it was useful to use Params to avoid needing a list,
but that is easily avoided.
Problems noticed while doing this conversion:
* Some uses of Params "oneword" which was entirely unnecessary
overhead.
* A few places that built up a list of parameters with ++
and then used Params to split it!
Test suite passes.
|
| |
|
|
| |
is disabled.
|
| | |
|
| |
|
|
|
| |
It was memoized, but that was not used consistently. Move it to
Types.GitConfig so it will auto-memoize.
|
| |
|
|
|
|
|
|
| |
The content file may not be owned by the user running git-annex, in which
case, setting the owner write bit was not enough to let lockContent
act on the file. However, with some core.sharedRepository configs, the file
should be writable by the user's group. So, the thing to do is to call
thawContent on it.
|
| |
|
|
|
|
|
|
|
|
|
| |
It was returning Just False in this situation, which differed from indirect
mode behavior. I don't think this led to any actual problems; things that
checked if the file being dropped was present just failed to fail, and
instead reported it wasn't present, possibly incorrectly.
Hmm, it's possible that this could have made git annex fsck --from remote
update the location log wrongly, if a remote was in direct mode, and was in
the middle of trying to drop a key, and the drop later failed.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also cleaned up the code, avoiding creating a lock file if we're going to
open it for create later anyway.
And, if there's an exception while preparing to lock the file, but not at
the point of actually taking the lock, throw an exception, instead of
silently not locking and pretending to succeed.
And, on Windows, always use lock file, even if the repo somehow got into
indirect mode (maybe with cygwin git..)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The one exception is in Utility.Daemon. As long as a process only
daemonizes once, which seems reasonable, and as long as it avoids calling
checkDaemon once it's already running as a daemon, the fcntl locking
gotchas won't be a problem there.
Annex.LockFile has it's own separate lock pool layer, which has been
renamed to LockCache. This is a persistent cache of locks that persist
until closed.
This is not quite done; lockContent stil needs to be converted.
|
| |
|
|
|
|
| |
get/unused/info commands are run.
Deleting lock files is tricky, tricky stuff. I think I got it right!
|
| |
|
|
|
| |
This affected callers that used forwardRetry; if the 1st attempt failed it
would clean up the transfer lock before retrying.
|
| |
|
|
|
|
| |
running at once.
As discussed in bug report.
|
| |
|
|
|
|
|
|
| |
Should be no behavior changes, just simplified code.
The only actual difference is it doesn't truncate the lock file.
I think that was a holdover from when transfer info was written to the lock
file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
used.
Only the assistant uses these, and only the assistant cleans them up, so
make only git annex transferkeys write them,
There is one behavior change from this. If glacier is being used, and a
manual git annex get --from glacier fails because the file isn't available
yet, the assistant will no longer later see that failed transfer file and
retry the get. Hope no-one depended on that old behavior.
|
| |
|
|
| |
annex.diskreserve.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Command/Fsck.hs
Messages.hs
Remote/Directory.hs
Remote/Git.hs
Remote/Helper/Special.hs
Types/Remote.hs
debian/changelog
git-annex.cabal
|
| | |
| |
| |
| | |
7.10
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The setDifferences that got added to initialize turns out to make a git
commit, and before ensureCommit has been used. Thus, repo init can fail
when the system has a broken hostname etc.
Move the ensureCommit to the very first thing to avoid this kind of breakage.
|
| | |
| |
| |
| |
| |
| |
| | |
getting content if the disk is too full.
We can't check if there's enough disk space to download the content,
but we *can* check if there's certainly not enough!
|
| |\|
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This works, and seems fairly robust. Clean get of 20 files at -J3. At -J10,
there are some messages about ssh multiplexing, probably due to a race
spinning up the ssh connection cacher. But, it manages to get all the files
ok regardless.
The progress bars are a scrambled mess though, due to bugs in
ascii-progress, which I've already filed. Particularly this one:
https://github.com/yamadapc/haskell-ascii-progress/issues/8
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
Windows is still building with an older git.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
Came up with a generic way to filter out progress messages while keeping
errors, for commands that use stderr for both.
--json mode will disable command outputs too.
|
| | | |
|
| |/
|
|
|
|
|
|
| |
well enough for sshcaching.
ssh tries to hard link a fifo, and if not, complains:
muxserver_listen: link mux listener .git/annex/ssh/SHARD1@iabak.archiveteam.org.QK8zOCbtNebI7q54 => .git/annex/ssh/SHARD1@iabak.archiveteam.org: Operation not permitted
|
| | |
|
| |
|
|
|
|
|
|
| |
This might be overkill; I only know I need it in ls-files, but other git
commands can also do their own globbing, it turns out, and I am pretty sure
I never want them too when git-annex is using them as plumbing.
Test suite still passes and it looks ok.
|
| |
|
|
|
|
|
|
|
| |
git-annex was installed from the standalone tarball.
This was introduced by commit 849a4b1a0d71071a602f552125fd7e25689662db
However, the same problem could affect other calls to programPath,
specifically some on the assistant. So, I fixed it at a deeper level.
|
| |
|
|
| |
git-annex branch.
|
| |
|
|
|
|
| |
updated. Needed for git update-server-info.
See https://github.com/datalad/datalad/issues/1#issuecomment-84094406
|
| |
|
|
| |
not supporting symlinks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems to work, but still experimental until it's been tested more.
When repositories are on filesystems not supporting symlinks, the .git dir
symlink trick cannot be used. Since we're going to be in direct mode
anyway, the .git dir symlink is not strictly needed.
However, I have not fixed the code that creates new annex symlinks to
handle this case -- the committed symlinks will be wrong.
git annex sync happens to currently fail in a submodule using direct mode,
because there's no HEAD ref. That also needs to be dealt with to get
this fully working in crippled filesystems.
Leaving http://github.com/datalad/datalad/issues/44 open until these issues
are dealt with.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
~/.config/git-annex/program, when possible.
Most of the time, there will be no discreprancy between programPath and
readProgramFile.
But, the programFile might have been written by an old version of git-annex
that is still installed, while a newer one is currently running. In this
case, we want to run the same one that's currently running.
This is especially important for things like the GIT_SSH=git-annex used for
ssh connection caching.
The only code that still uses readProgramFile directly is the upgrade code,
which needs to know where the standalone git-annex was installed, in order to
upgrade it.
|
| |
|
|
|
| |
Looking at the few current callers, it's ok to have programPath throw an
exception, in the unusual case where it cannot find git-annex.
|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out sqlite does not like having its database deleted out from
underneath it. It might suffice to empty the table, but I would rather
start each fsck over with a new database, so I added a lock file, and
running incremental fscks use a shared lock.
This leaves one concurrency bug left; running two concurrent fsck --more
will lead to: "SQLite3 returned ErrorBusy while attempting to perform step."
and one or both will fail. This is a concurrent writers problem.
|
| |
|
|
|
|
|
|
|
| |
* sync: Use the ssh-options git config when doing git pull and push.
* remotedaemon: Use the ssh-options git config.
Note that the rename env var means that if a new git-annex calls an old one
for git-annex ssh, or a new calls an old, nothing much will go wrong;
just ssh caching won't happen.
|
| |
|
|
| |
remotes that use ssh as a transport.
|
| | |
|
| | |
|
Joey Hess