summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/bugs/git-annex:_failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment28
-rw-r--r--doc/bugs/hash_changed.mdwn27
-rw-r--r--doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment10
-rw-r--r--doc/bugs/some_tests_fail_while_running_under_NFS.mdwn54
-rw-r--r--doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment7
-rw-r--r--doc/tips/messed_up_annex_by_using_git_checkout.mdwn40
-rw-r--r--doc/todo/add_sftp_backend.mdwn3
7 files changed, 169 insertions, 0 deletions
diff --git a/doc/bugs/git-annex:_failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment
new file mode 100644
index 000000000..2f3e560fa
--- /dev/null
+++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment
@@ -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...)
+"""]]
diff --git a/doc/bugs/hash_changed.mdwn b/doc/bugs/hash_changed.mdwn
new file mode 100644
index 000000000..cb1c1eefe
--- /dev/null
+++ b/doc/bugs/hash_changed.mdwn
@@ -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.
+
diff --git a/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment b/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment
new file mode 100644
index 000000000..87cbdedfc
--- /dev/null
+++ b/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment
@@ -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.
+"""]]
diff --git a/doc/bugs/some_tests_fail_while_running_under_NFS.mdwn b/doc/bugs/some_tests_fail_while_running_under_NFS.mdwn
new file mode 100644
index 000000000..2e87ff8a5
--- /dev/null
+++ b/doc/bugs/some_tests_fail_while_running_under_NFS.mdwn
@@ -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]]
diff --git a/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment b/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment
new file mode 100644
index 000000000..62ab93ca8
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_3_eaa9b0532d4629b61f3a684886b1d4f9._comment
@@ -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?
+"""]]
diff --git a/doc/tips/messed_up_annex_by_using_git_checkout.mdwn b/doc/tips/messed_up_annex_by_using_git_checkout.mdwn
new file mode 100644
index 000000000..f9b2eb63c
--- /dev/null
+++ b/doc/tips/messed_up_annex_by_using_git_checkout.mdwn
@@ -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
diff --git a/doc/todo/add_sftp_backend.mdwn b/doc/todo/add_sftp_backend.mdwn
new file mode 100644
index 000000000..386fec3c8
--- /dev/null
+++ b/doc/todo/add_sftp_backend.mdwn
@@ -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.