diff options
Diffstat (limited to 'doc/bugs')
5 files changed, 108 insertions, 0 deletions
diff --git a/doc/bugs/Drop_--from_always_trusts_local_repository.mdwn b/doc/bugs/Drop_--from_always_trusts_local_repository.mdwn new file mode 100644 index 000000000..a1b27cf5b --- /dev/null +++ b/doc/bugs/Drop_--from_always_trusts_local_repository.mdwn @@ -0,0 +1,44 @@ +### Please describe the problem. + +The command `git annex drop --from` always trusts the local repository, even if +it is marked as untrusted. + + +### What steps will reproduce the problem? +[[!format sh """ +mkdir t u; cd t; git init; git commit --allow-empty -m "Initial commit"; git annex init "Trusted"; date > file; git annex add file; git commit -m "Add file"; cd ../u; git init; git remote add t ../t; git fetch t; git merge t/master; git annex init "Untrusted"; git annex untrust .; git annex get file; cd ../t; git remote add u ../u; git fetch u; cd .. +"""]] + +Create two repositories, *t* (trusted) and *u* (untrusted). A file is in both +repositories. When performing `git annex drop file` in repository *t*, `git +annex` will abort because there are not enough copies. But when performing `git +annex drop --from t file` in *u*, git annex will delete the copy. + + +### What version of git-annex are you using? On what operating system? + +Bug was introduced with 6c31e3a8 and still exists in current master (d955cfe7). + + +### Please provide any additional information below. + +The following change seems to solve the problem. (First time working with +Haskell, please excuse the crude code.) + +[[!format diff """ +diff --git a/Command/Drop.hs b/Command/Drop.hs +index 269c4c2..09ea99a 100644 +--- a/Command/Drop.hs ++++ b/Command/Drop.hs +@@ -82,8 +82,9 @@ performRemote key afile numcopies remote = lockContent key $ do + (remotes, trusteduuids) <- Remote.keyPossibilitiesTrusted key + present <- inAnnex key + u <- getUUID ++ level <- lookupTrust u + let have = filter (/= uuid) $ +- if present then u:trusteduuids else trusteduuids ++ if present && level <= SemiTrusted then u:trusteduuids else trusteduuids + untrusteduuids <- trustGet UnTrusted + let tocheck = filter (/= remote) $ + Remote.remotesWithoutUUID remotes (have++untrusteduuids) +"""]] diff --git a/doc/bugs/assistant_eats_all_CPU.mdwn b/doc/bugs/assistant_eats_all_CPU.mdwn index 4939bf456..719fca425 100644 --- a/doc/bugs/assistant_eats_all_CPU.mdwn +++ b/doc/bugs/assistant_eats_all_CPU.mdwn @@ -520,3 +520,10 @@ $ ps -O start xf | grep git-annex 13761 23:56:38 Z ? 00:00:00 \_ [git] <defunct> 6252 12:56:59 S ? 00:01:09 /usr/bin/emacs23 """]] + +#### This bug is fixed + +> [[fixed|done]]. This was a Cronner bug, triggered when you had a +> scheduled fsck job that runs monthly at any time, and the last time it ran was on a day of a +> month > 12. Workaround: Disable scheduled fsck jobs, or change them to +> run on a specific day of the month. Or upgrade. --[[Joey]] diff --git a/doc/bugs/assistant_eats_all_CPU/comment_23_48a4c8d9dcc6cec243c6072090f26b6d._comment b/doc/bugs/assistant_eats_all_CPU/comment_23_48a4c8d9dcc6cec243c6072090f26b6d._comment new file mode 100644 index 000000000..b6d2dec76 --- /dev/null +++ b/doc/bugs/assistant_eats_all_CPU/comment_23_48a4c8d9dcc6cec243c6072090f26b6d._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.191" + subject="comment 23" + date="2014-04-11T16:32:47Z" + content=""" +<maxy> the clock_gettime(0x2 and clock_gettime(0x3 are consistent with getCurrentTime and getTimeZone of nextTime + +So, that strongly points to the Cronner thread, and I doubt this is specific to stable at all. + +Please run git-annex vicfg, and paste all the \"schedule\" lines, from a repository that has the problem. That should allow me to reproduce and fix this bug. +"""]] diff --git a/doc/bugs/git-annex_fails_to_initialize_under_Windows/comment_2_b9a3a0104bc56f9110fc58c9df140f12._comment b/doc/bugs/git-annex_fails_to_initialize_under_Windows/comment_2_b9a3a0104bc56f9110fc58c9df140f12._comment new file mode 100644 index 000000000..1fcfc5a51 --- /dev/null +++ b/doc/bugs/git-annex_fails_to_initialize_under_Windows/comment_2_b9a3a0104bc56f9110fc58c9df140f12._comment @@ -0,0 +1,34 @@ +[[!comment format=mdwn + username="ayutheos" + ip="49.124.177.13" + subject="comment 2" + date="2014-04-10T07:52:36Z" + content=""" +I'm getting this error too. + + user@NOTEBOOK /d/pictures + $ git annex init \"photos\" + init photos + Detected a filesystem without fifo support. + + Disabling ssh connection caching. + + Detected a crippled filesystem. + + Enabling direct mode. + fatal: index file open failed: Invalid argument + git-annex: git [Param \"checkout\",Param \"-q\",Param \"-B\",Param \"annex/direct/master\"] failed + +git-annex version: + + user@NOTEBOOK /d/pictures + $ git annex version + git-annex version: 5.20140403-gdfa17fc + build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash + key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL + remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external + local repository version: 5 + supported repository version: 5 + upgrade supported from repository versions: 2 3 4 + +"""]] diff --git a/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment new file mode 100644 index 000000000..d40d2d789 --- /dev/null +++ b/doc/bugs/git_annex_sync_in_direct_mode_does_not_honor_skip-worktree/comment_5_cb98789c50c58f01055183dbaf7b4eba._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="EvanDeaubl" + ip="24.251.129.149" + subject="comment 5" + date="2014-04-09T03:28:24Z" + content=""" +I'm afraid I abandoned this patch. It worked, but was still fidgety for being able to ignore parts of the tree. I found another way to do what I wanted by loading an indirect repo into /data and taking advantage of a surprise side effect in how the /sdcard filesystem translated the symlinks from the ext4 filesystem. + +I can probably scare it up from my archives, but it hasn't been kept up to date. The good news is (as I recall) the patch was pretty small. + +"""]] |