| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In v6 unlocked mode, this fixes a problem that was making eg,
echo > file cause the assistant to copy the file to the annex object,
instead of hard linking it. That because 2 change events were seen
(one for opening the file and one for closing) and processed together
the file was then locked down twice. Which meant it had mutiple hard links,
and so prevented linkAnnex from hard linking it.
There might be scenarios where multiple events come in, but staggered such
that a file gets locked down repeatedly, and it would still be copied to
the annex object in that case.
|
|
|
|
|
|
| |
This can happen when ingesting a new file in either locked or unlocked
mode, when some unlocked files in the repo use the same key, and the
content was not locally available before.
|
|
|
|
| |
Seems to basically work now!
|
|
|
|
| |
no behavior changes
|
|
|
|
| |
Files are not yet added to v6 repos in unlocked mode.
|
| |
|
|
|
|
|
| |
Will be used outside of direct mode for v6 unlocked files, and is already
used outside of direct mode when adding files to annex.
|
| |
|
|
|
|
|
|
|
| |
missed before.
It was used for regular pull, but not for regular push, tagged push, or the
fallback fetching.
|
|
|
|
| |
local copy be locked for removal
|
| |
|
|
|
|
|
|
|
|
|
| |
There should be no behavior changes in this commit, it just adds a more
expressive data type and adjusts code that had been passing around a [UUID]
or sometimes a Maybe Remote to instead use [VerifiedCopy].
Although, since some functions were taking two different [UUID] lists,
there's some potential for me to have gotten it horribly wrong.
|
|
|
|
|
|
|
|
| |
Also, rename lockContent to lockContentExclusive
inAnnexSafe should perhaps be eliminated, and instead use
`lockContentShared inAnnex`. However, I'm waiting on that, as there are
only 2 call sites for inAnnexSafe and it's fiddly.
|
|
|
|
| |
enabled when git-annex init is run.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This works, but needs more testing and work on cases like encrypted repos,
enabling existing repositories, etc.
This commit was sponsored by Shaun Westmacott.
|
|
|
|
|
|
|
|
|
|
| |
pairing to be the absolute path to the repository, not "."
This was a reversion caused by the relative path changes in 5.20150113.
Other uses of addAuthorizedKeys seem to be ok. If the user enters a
directory like ~/annex, it writes GIT_ANNEX_SHELL_DIRECTORY=annex, and
git-annex-shell assumes that's relative to HOME.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
merely a difference of opinion to you to do this is a bit of an asshole move. Just saying.
|
| |
|
|
|
|
|
|
|
| |
This no longer uses old-locale's defaultTimeLocale, but provides one
of its own.
Factored out a Logs.TimeStamp.
|
|
|
|
|
|
| |
I've tested all the dataenc to sandi conversions except Assistant.XMPP,
and all have unchanged behavior, including behavior on large unicode code
points.
|
|
|
|
| |
14.12.3 while still being compatable with 4.14.2. Thanks, silvio.
|
| |
|
|
|
|
| |
It's a code smell, can lead to hard to diagnose error messages.
|
| |
|
|
|
|
| |
command-line length limits and cause the commit to fail. This only happened when using the assistant in an indirect mode repository.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
~/.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.
|
|
|
|
|
|
| |
Note that while the assistant detects changes made to remote names, I left
the commit message fixed rather than calculating it after every commit. It
doesn't seem worth the CPU to do the latter.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
repository for the first time.
* init: Repository tuning parameters can now be passed when initializing a
repository for the first time. For details, see
http://git-annex.branchable.com/tuning/
* merge: Refuse to merge changes from a git-annex branch of a repo
that has been tuned in incompatable ways.
|
| |
|
|
|
|
|
|
|
|
| |
This is necessary for interop between inode caches created on unix and
windows. Which is more important than supporting inodecaches for large keys
with the wrong size, which are broken anyway.
There should be no slowdown from this change, except on Windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid using fileSize which maxes out at just 2 gb on Windows.
Instead, use hFileSize, which doesn't have a bounded size.
Fixes support for files > 2 gb on Windows.
Note that the InodeCache code only needs to compare a file size,
so it doesn't matter it the file size wraps. So it has been
left as-is. This was necessary both to avoid invalidating existing inode
caches, and because the code passed FileStatus around and would have become
more expensive if it called getFileSize.
This commit was sponsored by Christian Dietrich.
|
| |
|
|
|
|
|
|
|
|
| |
Reverts 2bba5bc22d049272d3328bfa6c452d3e2e50e86c
Unfortunately, this caused breakage on Windows, and possibly elsewhere,
because parentDir and takeDirectory do not behave the same when there is a
trailing directory separator.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
parentDir is less safe than takeDirectory, especially when working
with relative FilePaths. It's really only useful in loops that
want to terminate at /
This commit was sponsored by Audric SCHILTKNECHT.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Now bittorrent is another special case like web.
If the only remotes are web and bittorrent, it might as well scan those.
|