mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2016-03-09 13:13:28 -04:00
parent c6f81e8ef5
commit 0cdd4f9f58
Failed to extract signature
7 changed files with 169 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/git-annex:_failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment Normal file
View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="ellis"
subject="comment 5"
date="2016-03-09T10:04:14Z"
content="""
1) I'm afraid I don't have any real knowledge of VFAT -- always avoided it, but this is a shared drive, so it seemed best to just leave it with the factory formatting.
2) The output from `mount` is shown at the bottom of comment 3. The drive gets automounted when I plug it in.
3) \"Can you chmod the file to have some mode other than 444?\"
Yes. Here's a console transcript. After running `chmod 644`, git annex was able to drop the file.
% cd /media/ellis/USB04/repo/taiji-lib
% ls -l ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav
-r--r--r-- 1 ellis ellis 38464078 Mär 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav
% chmod 644 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav
% ls -l ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav
-rw-r--r-- 1 ellis ellis 38464078 Mär 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav
% git annex dropunused 101 --force
dropunused 101 ok
(recording state in git...)
"""]]

27
doc/bugs/hash_changed.mdwn Normal file
View file

@ -0,0 +1,27 @@
### Please describe the problem.
I ran `git annex fsck` on some files, and the fsck reported that hashes were incorrect and the files were moved.
### What steps will reproduce the problem?
I don't know.
### What version of git-annex are you using? On what operating system?
```
git-annex version: 6.20160229
build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL
remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external
```
on NixOS linux 64 bit - unstable channel
### Please provide any additional information below.
The problem was on several disks, different manufacturer, different disk size, etc. The fsck always transformed hashA -> hashB, so the hashes were equal before and after the fsck run on all disks, though the link to the "old" file was not fixed to point to the "new" file.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I use annex for years now, never had a problem with it. It is one of the most awesome pieces of software I've seen in the last 10 years, though I only use a really small part of it. Sometimes it bugs me a little that it consumes quite a lot of memory on large repositories, though most of the time this is not an issue for me.

10
doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="mail@f1d77c48f528d8c7b885900281887e045ad5114e"
nickname="mail"
subject="Solution"
date="2016-03-09T16:03:35Z"
content="""
The solution proposed by \"joeyh\" on irc was to remove the symlink (`git rm` it) and then move the actual file from .git/annex/bad back to the file and `git annex add` it again.
Worked beautifully.
"""]]

54
doc/bugs/some_tests_fail_while_running_under_NFS.mdwn Normal file
View file

@ -0,0 +1,54 @@
### Please describe the problem.
4 out of 269 tests failed (4468.00s)
hard to assess how critical they are...
### What steps will reproduce the problem?
run git annex test
### What version of git-annex are you using? On what operating system?
6.20160307+gitgb095561-1~ndall+1
### Please provide any additional information below.
[Full log](http://www.onerussian.com/tmp/git-annex-tests-6.20160307+gitgb095561-1~ndall+1.log)
[[!format sh """
smaug:/mnt/nfs/scrap/datalad/test_annex
$> grep -B5 FAIL git-annex-tests-6.20160307+gitgb095561-1~ndall+1.log
crypto: OK (50.57s)
preferred content: OK (20.36s)
add subdirs: OK (8.97s)
addurl: .t/tmprepo73/.git/annex/keys: removeDirectoryRecursive: unsatisfied constraints (Directory not empty)
sleeping 10 seconds and will retry directory cleanup
FAIL
--
293ed4c..c16b350 git-annex -> synced/git-annex
dd272eb..ffe1721 master -> synced/master
OK (11.64s)
addurl: .t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
sleeping 10 seconds and will retry directory cleanup
FAIL
--
0993b09..c09ddc4 git-annex -> synced/git-annex
a823824..520f58c master -> synced/master
OK (13.67s)
addurl: .t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
sleeping 10 seconds and will retry directory cleanup
FAIL
--
OK (14.59s)
addurl: On branch master
nothing to commit, working directory clean
.t/tmprepo73/.git/annex/keys/.nfs0000000009a305870000020e: removeDirectoryRecursive: resource busy (Device or resource busy)
sleeping 10 seconds and will retry directory cleanup
FAIL
# End of transcript or log.
"""]]
[[!meta author=yoh]]

7
doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment Normal file
View file

@ -0,0 +1,7 @@
[[!comment format=mdwn
username="nasava"
subject="Ancient variant for Armel"
date="2016-03-08T22:02:29Z"
content="""
I have a NAS running Linux Kernel 2.6.36 unfortunately not possible updating it. The newest standalone build complains about \"kernel too old\". Is there a variant somewhere for ancient armel also like for x86_32? Or how can I build one?
"""]]

40
doc/tips/messed_up_annex_by_using_git_checkout.mdwn Normal file
View file

@ -0,0 +1,40 @@
Hello. Linux experienced user here, but with no development or git experience ever. This directly leads me to my biggest trouble with git-annex because I constantly suffer from misunderstanding each and everything. That being said, my problem is the following: I had the terrible idea to have my .thunderbird directory synchronized over several machines, leading the thunderbird profile to total corruption because after a few weeks I finally managed to have multiple machines accessing it. As I started trying to recover, things got worse and this is my last seek for help before starting over by creating the repositories from scratch.
What I did:
1. I did some research on how to recover an old state of the repo, which should not have been a problem because there is a "full backup" repo. I came across this [1] page and the pain started with me looking for my wanted commit to roll-back in "git log" and then did some tries in the way something like, "git checkout -b old-state4 012345678".
2. Of course this recovered the whole repo and not only thunderbird, so I used a file synchronizer to put everything else back into place after the action.
3. Unfortunately, the "branches" seem to have been messed up and the repos are no longer in sync.
This is what the machine says that I have used to create the mess:
[2016-03-08 19:15:26.915116] Pusher: Syncing with host123
(recording state in git...)
To ssh://user@10.0.0.1/mnt/foo/bar
d35c699..fed0636 git-annex -> synced/git-annex
a44bfb2..818b7b5 annex/direct/old_state4 -> synced/old_state4
This is what another machine says:
[2016-03-08 21:17:48.649949] Pusher: Syncing with host123
(recording state in git...)
To ssh://user@10.0.0.1/mnt/foo/bar
423f50f..4c8fad8 annex/direct/master -> q/annex/direct/master
2a67458..fed0636 git-annex -> host123/git-annex
6a1076b..4c8fad8 master -> host123/master
7f55414..818b7b5 old_state4 -> host123/old_state4
Long story, short...
I apologize for being a total git noob while at the same time performing git magic leading into a total desaster.
However, I hope someone can give me a hint what to do to have the "old_state4" solved?
Also, I really would like to get used to the git internals but since git is quite powerful, I always get overwhelmed because the tutorials out there are either developer-focused (which I'm not in the correct target group) or they simply cover each and everything (which is of no use because I don't want to administrate a GitHub repo but a private git-annex for my files and documents).
Thank you so much!
[1] http://stackoverflow.com/questions/4114095/revert-git-repo-to-a-previous-commit

3
doc/todo/add_sftp_backend.mdwn Normal file
View file

@ -0,0 +1,3 @@
A sftp backend would be nice because gpg operations could be pipelined to the network transfer, not requiring the creation of a full file to disk with gpg before the network transmission, as it happens with rsync.
There should be some libraries that can handle the sftp connections and transfers. I read that even curl has support for that.