| Commit message (Collapse) | Author | Age |
|
|
|
| |
the git-annex branch, so it works when run in a subdirectory. This bug affected git-annex unused, and potentially also transitions running code and other things.
|
|
|
|
| |
found a use case for it. Note that the command's syntax was changed for consistency.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
rejected on the other end for security reasons.
|
|
|
|
| |
might be left over from a previous login session and so unable to use the ssh agent of a new login session.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes git annex unused use around 48 mb more memory than it did before,
but the massive increase in accuracy makes this worthwhile for all but the
smallest systems.
Also, I want to use the bloom filter for sync --all --content, to avoid
dropping files that the preferred content doesn't want, and 1/1000
false positives would be far too many in that use case, even if it were
acceptable for unused.
Actual memory use numbers:
1000: 21.06user 3.42system 0:26.40elapsed 92%CPU (0avgtext+0avgdata 501552maxresident)k
1000000: 21.41user 3.55system 0:26.84elapsed 93%CPU (0avgtext+0avgdata 549496maxresident)k
10000000: 21.84user 3.52system 0:27.89elapsed 90%CPU (0avgtext+0avgdata 549920maxresident)k
Based on these numbers, 10 million seemed a better pick than 1 million.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
--content
backup: Use new "anything" terminal. This means that content that
is not unused, but has no associated file will be wanted by backup repos.
unwanted: "not anything" will result in any and all content moving
off of these repos.
incremental backup: Remove the "(include=* or unused)",
so it matches content that has no associated files
but is not unused.
client: Add a include=* to the expression. This limits it to matching
only files in the work tree. Without this change, sync --all --content
would match a key against the expression, and since it matches
exclude=archive/*, the client repo would have wanted the file content.
The "and not unused" would have kept unused objects out, but not
objects that were not known to be unused, or objects that another branch
referred to. In practice, everything would have flooded into client repos
without this change.
|
|
|
|
|
|
| |
documentation, which says it does not want files that have reached a backup repository.
Checked history and these have been out of sync from the very beginning!
|
|
|
|
| |
versions of all files.
|
| |
|
|
|
|
| |
"repositories containing these files", and "transfers in progress".
|
| |
|
| |
|
|
|
|
|
|
| |
their paths.
Ie, "https://archive.org/download/zoom-2/Zoom - Release 2 (1996)(Active Software)[!].iso"
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
ikiwiki feature.) Closes: #785736
|
|
|
|
| |
versions of tahoe create-client choking.
|
| |
|
| |
|
| |
|
|
|
|
| |
in a bare repo. Otherwise, still reports files with lost contents, even if the content is dead.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In my tests, this has to be set when uploading a file to the bucket
and then the file can be accessed using the bucketname.s3.amazonaws.com
url.
Setting it when creating the bucket didn't seem to make the whole bucket
public, or allow accessing files stored in it. But I have gone ahead and
also sent it when creating the bucket just in case that is needed in some
case.
|
|
|
|
| |
copy of a file as one of the necessary copies to allow removing it from the import location.
|
| |
|
|
|
|
| |
network connections, as was already done with network-manager and wicd. Thanks to Sebastian Reuße for the patches.
|
|
|
|
| |
is disabled.
|
|
|
|
| |
parsable as strange keys.
|
| |
|
|
|
|
| |
now moved to the bad directory, and the fsck proceeds. Before, the fsck immediately failed.
|
|
|
|
| |
are not ready for this change yet and it prevented them from building the webapp. Reopens: #786659
|
|
|
|
| |
vars, so that it will work when eg, untarred into a directory path with spaces in its name.
|
| |
|
|
|
|
|
|
|
|
| |
generate URL keys.
This is especially useful because the caller doesn't need to generate valid
url keys, which involves some escaping of characters, and may involve
taking a md5sum of the url if it's too long.
|
| |
|
|
|
|
| |
will find it. Fixes OSX upgrade going forward, but older versions won't upgrade themselves due to this problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
#785498
|
| |
|
| |
|
|
|
|
| |
rather than the default of considering all refs used.
|
|
|
|
|
|
| |
get/unused/info commands are run.
Deleting lock files is tricky, tricky stuff. I think I got it right!
|
|
|
|
|
|
| |
running at once.
As discussed in bug report.
|