| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
(not actually used anywhere yet)
|
| |
|
|
|
|
|
| |
missed before.
It was used for regular pull, but not for regular push, tagged push, or the
fallback fetching.
|
| | |
|
| |
|
|
|
| |
keyLocations doesn't return locations in dead repos, but if we're fscking a
dead repo, we want to look at what locations are actually logged for it.
|
| |
|
|
|
|
|
| |
desktop file, and base completion file, same as the regular git-annex.deb.
It already had a doc-base file relating to the html documentation, and
there's no reason not to include the other stuff.
|
| |
|
|
| |
into $HOME/.ssh
|
| | |
|
| |
|
|
| |
support that; avoid crashing on such invalid encoding.
|
| |
|
|
|
|
| |
of the annex back to the file, because other files may point to that same content. Instead, copy the injected file content out to recover.
That was not a data loss, but it came close!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
replaceFile created a temp file, which was guaranteed to not overlap with
another temp file. However, makeAnnexLink then deleted that file, in
preparation for making the symlink in its place. This caused a race, since
some other replaceFile could create a temp file, using the same name!
I was able to reproduce the race easily running git-annex add -J10 in a
directory with 100 files (all with different contents). Some files would
get ingested into the annex, but their annex links would fail to be added.
There could be other situations where this same problem could occur.
Perhaps when the assistant is adding a file, if the user manually also ran
git-annex add. Perhaps in cases not involving adding a file.
The new replaceFile makes a temprary directory, which is guaranteed to be
unique, and doesn't make a temp file in there. makeAnnexLink can thus
create the symlink without problem and the race is avoided.
Audited all calls to replaceFile to make sure that the old behavior of
providing an empty temp file was not relied on.
The general problem of asking for a temp file and deleting it as part of
the process of using it could reach beyond replaceFile. Did some quick
audits and didn't find other cases of it. Probably only symlink creation
stuff would tend to make that mistake, mostly.
|
| |
|
|
| |
moves file contents around.
|
| |
|
|
| |
to is not a directort, but perhaps an annexed file.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Output without -Jn should be unchanged from before. With -Jn,
concurrent-output is used for messages, but regions are not used yet, so
it's a mess.
|
| |
|
|
|
| |
Seems that some changes to the cabal file a few months ago resulted in a
git-annex that broke stackage infrastructure.
|
| |
|
|
|
|
|
|
|
| |
display a warning, but continue successfully.
Installing the desktop file etc is a niceity of git-annex's cabal install,
but not a requirement.
closes https://github.com/fpco/stackage/issues/726
|
| |
|
|
| |
run as root, since that is not a systemwide install, but to /root, and so generating a systemwide desktop file is not right.
|
| | |
|
| |
|
|
|
|
| |
* Fix failure to build with aws-0.13.0.
* When built with aws-0.13.0, the S3 special remote can be used to create
google nearline buckets, by setting storageclass=NEARLINE.
|
| |
|
|
| |
seems it now prefers repo in this case, although historically it may have preferred repo.git.
|
| |
|
|
| |
and accept either the uuid or the description in leu if the name.
|
| | |
|
| |
|
|
| |
available, which should be more portable.
|
| |
|
|
|
|
|
|
| |
Fixes a recent-ish build warning on about 64 bit vs non.
This is the method used by the disk-free-space library, and I tested it to
yield the same results on even 10 tb drives on OSX -- so it's getting 64
bit values.
|
| |
|
|
| |
there can be only one.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
have an annex.uuid set.
Instead, only display transport error if the configlist output doesn't
include an annex.uuid line, even an empty one.
A recent change made git-annex init try to get all the remote uuids, and so
the transport error would be displayed by it. It was also displayed when
eg, copying files to a remote that had no uuid yet.
|
| |
|
|
|
|
|
|
|
|
| |
resolved
sync, merge, assistant: When git merge failed for a reason other than a
conflicted merge, such as a crippled filesystem not allowing particular
characters in filenames, git-annex would make a merge commit that could
omit such files or otherwise be bad. Fixed by aborting the whole merge
process when git merge fails for any reason other than a merge conflict.
|
| |
|
|
| |
Was using the http-only Manager before, not the tls-capable one.
|
| |
|
|
| |
to drop from remotes first and from the local repo last. This works better with the behavior changes to drop in many cases.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added back with unchanged content.
Implemented with no additional overhead of compares etc.
This is safe to do for presence logs because of their locality of change;
a given repo's presence logs are only ever changed in that repo, or in a
repo that has just been actively changing the content of that repo.
So, we don't need to worry about a split-brain situation where there'd
be disagreement about the location of a key in a repo. And so, it's ok to
not update the timestamp when that's the only change that would be made
due to logging presence info.
|
| |
|
|
|
|
|
|
| |
/dev/null stderr; ssh is still able to display a password prompt
despite this
Show some messages so the user knows it's locking a remote, and
knows if that locking failed.
|
| | |
|
| | |
|
| |
|
|
| |
content.
|
| |
|
|
| |
Backporters will need to revert this.
|
| |
|
|
| |
recommending bittornado | bittorrent.
|
| |
|
|
| |
checking what --to should, and vice-versa.) Fixed this bug, which was introduced in version 5.20150727.
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Solaris, using f_bsize provided a value that is apparently much larger
than the real block size. The solaris docs for statvfs say
f_bsize is the "preferred" file system block size, and I guess the
filesystem prefers larger blocks, but uses smaller ones or something.
The docs also say that f_frsize is the "fundamental" block size.
Switched to using f_frsize on Linux and kFreeBSD too, since I guess
f_bsize could in theory vary the same way there too. Assuming that Solaris
is not violating the posix spec, I guess the linux man page for statvfs
is not as well written and I misunderstood it.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Update install instructions.
Note that xmpp is disabled in the stack.yaml, because that needs C
libraries that would take extra work for the user to install.
xmpp is moving toward deprecation anyway.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems easy, but git ls-files can't list the right subset of files.
So, I wrote a whole new parser for git status output, and converted the
status command to use that.
There are a few other small behavior changes. The order changed. Unlocked
files show as T. In indirect mode, deleted files were not shown before, and
that's fixed. Regular files checked directly into git and modified
were not shown before, and are now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
is missing.
I couldn't find a good way to make an *empty* index file (zero byte file
won't do), so I punted and just don't make index.lock when there's no index
yet. This means some other git process could race and write an index file
at the same time as the merge is ongoing, in theory. Only happens in new
repos though.
|
| | |
| |
| |
| |
| |
| |
| | |
it cannot parse.
"Host\n" is a valid line, and actually gets parsed ok, but this also holds
for other lines that it fails to parse for some reason.
|
Joey Hess
Henrik Ahlgren