diff options
Diffstat (limited to 'doc/bugs')
13 files changed, 338 insertions, 0 deletions
diff --git a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5.mdwn b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5.mdwn index 5f7166ed3..f2ff38702 100644 --- a/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5.mdwn +++ b/doc/bugs/Set_some_reasonable_requirements_lower-bound_for_linux_standalone_builds:_no_longer_usable_on_CentOS_6.5.mdwn @@ -2,3 +2,7 @@ standalone builds leap forward a bit too fast in terms of their demand on modern kernel. Up until a month ago, standalone build worked at least on CentOS 6.5 with 2.6.32-431.11.2.el6.x86_64 (although [already didn't on ancient but still in use RHEL5 with 2.6.18](https://github.com/datalad/datalad/issues/176#issuecomment-114612365)). Current build from 20150916 doesn't work on CentOS 6.5 any longer. No matter how much I like people to use more recent releases of their distributions, it is infeasible to demand people to do that. It would be great if standalone builds were carried out on some elder kernel/libc environment to make git-annex standalone builds usable there. +> [[done]]; the ancient build provides this. It's now build with stack, so +> it gets most features enabled. (Except xmpp, notably.) This does mean +> it will only get library security fixes once git-annex's stack.yaml +> is updated to require a new version of the affected library. --[[Joey]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn index 613e11eae..51894cac6 100644 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn +++ b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn @@ -79,3 +79,6 @@ The diff probably needs check, improvement... Not tested this "feature" yet, I got another issue which blocks me for now. +> Well, this code has been removing from git-annex, and it's now using +> <http://hackage.haskell.org/package/disk-free-space>. I think that +> library is somewhat more portable. [[done]] diff --git a/doc/bugs/git-annex:_failed_to_lock_content.mdwn b/doc/bugs/git-annex:_failed_to_lock_content.mdwn new file mode 100644 index 000000000..f036f1353 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content.mdwn @@ -0,0 +1,107 @@ +### Please describe the problem. + +Cannot drop unused files on a USB drive, failing with the error message "git-annex: failed to lock content". + +### What steps will reproduce the problem? + +1. Installed stand-alone verison of git-annex on Ubuntu sometime last month +2. Created a repository on my main HD, upgraded to v6 +3. Added files to it +4. Created a USB (vfat) repo using the webapp without encryption; stopped the webapp, and ran `git annex get` on the USB repo. +5. Saw that I had added some files to the repo by mistake, and used `git annex unannex $FILES` on the main HD, then `git annex unused`, then `git annex dropunused 1-101` +6. Re-synced both repos +7. In the USB repo, `git annex unused` showed the same list as on the HD. +8. `git annex dropunused 1-101` then fails +9. Installed the latest stand-alone version (6.20160229-gbe4820c) +10. tried dropping again, didn't work; reboot the computer; tried dropping again, didn't work. +11. ran `git annex upgrade` on USB repo, tried dropping agian, no success + +### What version of git-annex are you using? On what operating system? + +* git annex version 6.20160229-gbe4820c +* Ubuntu 15.10 + +### Please provide any additional information below. + +[[!format sh """ +/media/ellis/USB04/repo/taiji-lib +% cat annex/unused +2 SHA256E-s562039928--04903c0b7d4e16062b3dc0bf17a84ce7943545d9437b80947ff98a3d3483e66e.AVI 1457129072.853555s +101 SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav 1457129072.853555s +... +44 SHA256E-s561941624--fdf6f89d9403464d4c494eac67fc1525aa6b9b0adc96be99f7d42e7f5472e44c.avi 1457129072.853555s + +/media/ellis/USB04/repo/taiji-lib +% git annex dropunused 101 --debug 13:09:28 +[2016-03-05 13:09:28.675403] read: git ["--git-dir=.","--literal-pathspecs","show-ref","git-annex"] +[2016-03-05 13:09:28.677635] process done ExitSuccess +[2016-03-05 13:09:28.67773] read: git ["--git-dir=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] +[2016-03-05 13:09:28.679775] process done ExitSuccess +[2016-03-05 13:09:28.680234] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..aee0b39b5232c369721c08eb782a7143ba2f8901","-n1","--pretty=%H"] +[2016-03-05 13:09:28.685879] process done ExitSuccess +[2016-03-05 13:09:28.686006] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..2b2b2747a6533f115867cc7a70a426764fc90286","-n1","--pretty=%H"] +[2016-03-05 13:09:28.688135] process done ExitSuccess +[2016-03-05 13:09:28.688227] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..4f4acf1555539a7bcb520e4befbeab803f220f67","-n1","--pretty=%H"] +[2016-03-05 13:09:28.690357] process done ExitSuccess +[2016-03-05 13:09:28.691327] chat: git ["--git-dir=.","--literal-pathspecs","cat-file","--batch"] +dropunused 101 git-annex: failed to lock content: ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav: openFd: permission denied (Permission denied) + +/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 Mar 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav + +/media/ellis/USB04/repo/taiji-lib +% strace -e file -f git annex dropunused 101 --debug +... +[pid 4646] openat(AT_FDCWD, "./objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 +[pid 4646] access("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.keep", F_OK) = -1 ENOENT (No such file or directory) +[pid 4646] stat("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.pack", {st_mode=S_IFREG|0644, st_size=828068, ...}) = 0 +[pid 4646] access("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.keep", F_OK <unfinished ...> +[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=1, si_value=0} --- +[pid 4646] <... access resumed> ) = -1 ENOENT (No such file or directory) +[pid 4646] stat("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.pack", {st_mode=S_IFREG|0644, st_size=55237, ...}) = 0 +[pid 4646] access("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.keep", F_OK) = -1 ENOENT (No such file or directory) +[pid 4646] stat("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.pack", {st_mode=S_IFREG|0644, st_size=116702, ...}) = 0 +[pid 4646] access("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.keep", F_OK) = -1 ENOENT (No such file or directory) +[pid 4646] stat("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.pack", {st_mode=S_IFREG|0644, st_size=116197, ...}) = 0 +[pid 4646] getcwd("/media/ellis/USB04/repo/taiji-lib", 129) = 34 +[pid 4646] open("./objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory) +[pid 4646] open("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.idx", O_RDONLY|O_NOATIME) = 3 +[pid 4646] open("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.idx", O_RDONLY|O_NOATIME) = 3 +[pid 4646] open("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.idx", O_RDONLY|O_NOATIME) = 3 +[pid 4646] open("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.idx", O_RDONLY|O_NOATIME) = 3 +[pid 4646] open("./objects/ae/e0b39b5232c369721c08eb782a7143ba2f8901", O_RDONLY|O_NOATIME) = 3 +[pid 4646] open("./objects/1d/ca126189c826e37b03897754fab7e8a8687683", O_RDONLY|O_NOATIME) = 3 +[pid 4636] stat("./annex/unused", {st_mode=S_IFREG|0644, st_size=11160, ...}) = 0 +[pid 4636] open("./annex/unused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 +[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- +[pid 4636] stat("./annex/badunused", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +[pid 4636] open("./annex/badunused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 +[pid 4636] stat("./annex/tmpunused", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 +[pid 4636] open("./annex/tmpunused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 +dropunused 101 [pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 +[pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 +[pid 4636] stat("./annex", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0 +[pid 4636] open("./annex/keys.lck", O_RDWR|O_CREAT, 0666) = 11 +[pid 4636] stat("./annex/keys/db", 0x7f2247d0ceb0) = -1 ENOENT (No such file or directory) +[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=9, si_value=0} --- +[pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 +[pid 4636] open("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", O_RDWR) = -1 EACCES (Permission denied) +git-annex: failed to lock content: ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav: openFd: permission denied (Permission denied) +[pid 4638] +++ exited with 0 +++ +[pid 4639] +++ exited with 0 +++ +[pid 4637] +++ exited with 0 +++ +[pid 4636] +++ exited with 1 +++ +[pid 4623] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4636, si_status=1, si_utime=1, si_stime=4} --- +[pid 4623] +++ exited with 1 +++ ++++ exited with 0 +++ + +"""]] + +Could the problem have something to do with the file having permission 0444 and trying to opening it O_RDWR? + +### 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) + +Been using it since your kickstarter campaign! + +> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex:_failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment new file mode 100644 index 000000000..a6fef26b2 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment @@ -0,0 +1,25 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-03-07T16:58:35Z" + content=""" +I replicated this as best I could, and the dropunused succeeded. But my +strace has an extra chmod: + + stat("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", {st_mode=S_IFREG|0444, st_size=30, ...}) = 0 + stat("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", {st_mode=S_IFREG|0444, st_size=30, ...}) = 0 + chmod("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", 0100644) = 0 + open("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", O_RDWR) = 16 + +So, it kind of looks like it checked the permissions and decided 0444 was good +enough and didn't chmod it to allow write (in order to lock it for removal). + +The only way I can see how that could perhaps happen is if git-anenx thinks +it's in a crippled filesystem that doesn't support chmod. But then the file +shouldn't be locked down like that. I was, though, able to reproduce +that behavior after running `git config annex.crippledfilesystem true` + +So, I need more information: What filesystem is the USB drive formatted with, +and can you run `git config --list` in the git repository on the drive and +paste the output please. +"""]] diff --git a/doc/bugs/git-annex:_failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment new file mode 100644 index 000000000..b71f04a55 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment @@ -0,0 +1,31 @@ +[[!comment format=mdwn + username="ellis@9dd4c3615b5ff78a457c5832488610886fd6b255" + nickname="ellis" + subject="comment 2" + date="2016-03-08T19:26:03Z" + content=""" +Thanks Joey, here's the output from `git config --list`: + + color.diff=auto + color.status=auto + color.branch=auto + push.default=simple + core.precomposeunicode=true + credential.helper=/usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring + core.repositoryformatversion=0 + core.filemode=false + core.bare=true + core.symlinks=false + core.ignorecase=true + core.fsyncobjectfiles=true + annex.uuid=a8ed0f4a-47c9-4289-947d-2f4650e9ede6 + annex.sshcaching=false + annex.crippledfilesystem=true + annex.version=6 + remote.lorax.url=../../../../../mnt/taiji07/taiji-lib + remote.lorax.fetch=+refs/heads/*:refs/remotes/lorax/* + remote.lorax.annex-uuid=9ea9a021-e3c6-4d55-a118-f3f55387ef40 + filter.annex.smudge=git-annex smudge %f + filter.annex.clean=git-annex smudge --clean %f + +"""]] diff --git a/doc/bugs/git-annex:_failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment new file mode 100644 index 000000000..fd50fb028 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="ellis" + subject="comment 3" + date="2016-03-08T19:52:21Z" + content=""" +And the file system is VFAT: + + /dev/sde1 on /media/ellis/USB04 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) +"""]] diff --git a/doc/bugs/git-annex:_failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment new file mode 100644 index 000000000..4c29c33e2 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2016-03-08T20:38:25Z" + content=""" +Thanks, that's consistent with my analysis. + +The only thing I don't understand is how a file on a vfat filesystem can +have mode 444. When I make a vfat filesystem and mount it on linux, +chmod doesn't change the mode of files at all; they're hardcoded at 755. + +Is your drive mounted with any interesting mount options? Paste the output +from `mount` for the drive. + +Can you chmod the file to have some mode other than 444? +"""]] 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/git-annex:_failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment b/doc/bugs/git-annex:_failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment new file mode 100644 index 000000000..cebc1f0c1 --- /dev/null +++ b/doc/bugs/git-annex:_failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2016-03-09T17:31:18Z" + content=""" +Ok, I managed to get a vfat that honors file perms with those mount +options. + +I'm going to make git-annex always try to chmod the file, even if it's on a +crippled filesystem. That should solve it. +"""]] diff --git a/doc/bugs/hash_changed.mdwn b/doc/bugs/hash_changed.mdwn new file mode 100644 index 000000000..44f2d2eba --- /dev/null +++ b/doc/bugs/hash_changed.mdwn @@ -0,0 +1,32 @@ +### 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. + +> I think this was not a bug in hashing, just a corrupted file that +> spread to several repositories. More recent git-annex versions checksum +> files after transfer so detect the problem. +> +> Since it was resolved to reporter's satisfaction, [[done]] --[[Joey]] 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/bugs/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment b/doc/bugs/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment new file mode 100644 index 000000000..f52704041 --- /dev/null +++ b/doc/bugs/some_tests_fail_while_running_under_NFS/comment_1_8e0f72f633ec79bd373b009046ab66b7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-03-09T17:15:13Z" + content=""" +This is all down to those nfs lock files, so finding a way to probe for an +NFS system and auto-enable pidlock is the best way to fix this. +"""]] |