diff options
Diffstat (limited to 'doc/bugs')
63 files changed, 1286 insertions, 2 deletions
diff --git a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__.mdwn b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__.mdwn index dfc1cc4ad..d7035432a 100644 --- a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__.mdwn +++ b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__.mdwn @@ -15,3 +15,8 @@ Add a repository on a Box.net server to an existing repository from the webapp ( git annex 5.20140128-g32f1f68 on Android 4.1.2 (Samsung GTN8010) Build flags: Assistant Webapp S3 WebDAV Inotify XMPP DNS Feeds Quvi TDFA CryptoHash + +> Cooincidentially I noticed I'd dropped the patch that fixes that on +> Android, and have been in the process of rebuilding the Android +> autobuilder with it today. That build has finished now. [[done]] +> --[[Joey]] diff --git a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_1_91787407727f7ed833d5970d3226d0cb._comment b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_1_91787407727f7ed833d5970d3226d0cb._comment new file mode 100644 index 000000000..45d5da95e --- /dev/null +++ b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_1_91787407727f7ed833d5970d3226d0cb._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkI9pq1WH6MWeExXHVQVEsniT3DdFv4AB8" + nickname="Roberto" + subject="problem still persists" + date="2014-02-10T22:55:33Z" + content=""" +I'm trying right now the latest build (5.20140210-gd99db49) but the problem persists. Am I missing something? +"""]] diff --git a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_2_f4c52fe33e9c4c107c2469fabb0c6826._comment b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_2_f4c52fe33e9c4c107c2469fabb0c6826._comment new file mode 100644 index 000000000..d566170c9 --- /dev/null +++ b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_2_f4c52fe33e9c4c107c2469fabb0c6826._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 2" + date="2014-02-10T23:25:42Z" + content=""" +Hmm, I've verified that the certificate library I built for android uses the right path. But for some reason that path is not showing up in the android executable. + +I think perhaps things have changed and a different library is now being used! Probably <http://hackage.haskell.org/package/x509-system> +"""]] diff --git a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_3_20c1f9399321dd85cb584b8845140b1d._comment b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_3_20c1f9399321dd85cb584b8845140b1d._comment new file mode 100644 index 000000000..d728e35a8 --- /dev/null +++ b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_3_20c1f9399321dd85cb584b8845140b1d._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="finished rebuilding everything" + date="2014-02-11T17:48:07Z" + content=""" +All android builds are updated. Verified the path this time in the binary. +"""]] diff --git a/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_4_d92c30061e087878a2462b5a2e495346._comment b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_4_d92c30061e087878a2462b5a2e495346._comment new file mode 100644 index 000000000..299364913 --- /dev/null +++ b/doc/bugs/Android:_Adding_Repository_on_Box.net_fails_with___34__Internal_Server_Error__34__/comment_4_d92c30061e087878a2462b5a2e495346._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkI9pq1WH6MWeExXHVQVEsniT3DdFv4AB8" + nickname="Roberto" + subject="fix confirmed" + date="2014-02-12T12:05:42Z" + content=""" +I can confirm the problem is now fixed. + +Unfortunately a new problem has emerged with gpg that might be related to other open issues. I will try to investigate it further before opening a new ticket. + +By the way thank you very much for your great work. I'm eager to see the new metadata framework in place. It sounds extremely interesting! +"""]] diff --git a/doc/bugs/Auto_update_not_updating_to_newest_version/comment_5_ab1ee005dbd54e560ea6e3c716cc8f1b._comment b/doc/bugs/Auto_update_not_updating_to_newest_version/comment_5_ab1ee005dbd54e560ea6e3c716cc8f1b._comment new file mode 100644 index 000000000..b05a0b1e2 --- /dev/null +++ b/doc/bugs/Auto_update_not_updating_to_newest_version/comment_5_ab1ee005dbd54e560ea6e3c716cc8f1b._comment @@ -0,0 +1,70 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo" + nickname="Dirk" + subject="Still problems" + date="2014-02-14T11:30:10Z" + content=""" +There seem to be still problems here. + +I removed all my old configurations and repositories and reinstalled the newest version from the site. After starting I get a message about an update being available. I update and end up with the same version. + +[[!format sh \"\"\" +[2014-02-14 12:22:10 CET] main: starting assistant version 5.20140209-g3a61dbe +(scanning...) [2014-02-14 12:22:10 CET] Watcher: Performing startup scan +(started...) [2014-02-14 12:22:10 CET] Upgrader: An upgrade of git-annex is available. (version 5.20140210) +--2014-02-14 12:23:24-- https://downloads.kitenet.net/git-annex/OSX/current/10.9_Mavericks/git-annex.dmg +Resolving downloads.kitenet.net... 80.68.85.49, 2001:41c8:125:49::10 +Connecting to downloads.kitenet.net|80.68.85.49|:443... connected. +HTTP request sent, awaiting response... 200 OK +Length: 29053083 (28M) [application/x-apple-diskimage] +Saving to: ‘/Users/kraft/Desktop/annex/.git/annex/tmp/SHA256E-s29053083--ee629137b511da8b874cdac78ece54b344b2b2a1763e4bf806949c9868117b13.dmg’ + + 0K .......... .......... .......... .......... .......... 0% 2.46M 11s + 50K .......... .......... .......... .......... .......... 0% 1.69M 14s + 100K .......... .......... .......... .......... .......... 0% 4.39M 11s + 150K .......... .......... .......... .......... .......... 0% 2.28M 11s + 200K .......... .......... .......... .......... .......... 0% 7.15M 10s + 250K .......... .......... .......... .......... .......... 1% 2.30M 10s + 300K .......... .......... .......... .......... .......... 1% 15.5M 9s + + 28300K .......... .......... .......... .......... .......... 99% 11.0M 0s + 28350K .......... .......... .. 100% 16.8M=2.8s + +2014-02-14 12:23:28 (9.96 MB/s) - ‘/Users/kraft/Desktop/annex/.git/annex/tmp/SHA256E-s29053083--ee629137b511da8b874cdac78ece54b344b2b2a1763e4bf806949c9868117b13.dmg’ saved [29053083/29053083] + +[2014-02-14 12:23:28 CET] main: Downloaded git-annex.. upgrade) +Checksumming Protective Master Boot Record (MBR : 0)… +Protective Master Boot Record (MBR :: verified CRC32 $BFC39E6D +Checksumming GPT Header (Primary GPT Header : 1)… + GPT Header (Primary GPT Header : 1): verified CRC32 $3488C834 +Checksumming GPT Partition Data (Primary GPT Table : 2)… +GPT Partition Data (Primary GPT Tabl: verified CRC32 $CABDFFA1 +Checksumming (Apple_Free : 3)… + (Apple_Free : 3): verified CRC32 $00000000 +Checksumming disk image (Apple_HFS : 4)… + disk image (Apple_HFS : 4): verified CRC32 $0CFF6F1A +Checksumming (Apple_Free : 5)… + (Apple_Free : 5): verified CRC32 $00000000 +Checksumming GPT Partition Data (Backup GPT Table : 6)… +GPT Partition Data (Backup GPT Table: verified CRC32 $CABDFFA1 +Checksumming GPT Header (Backup GPT Header : 7)… + GPT Header (Backup GPT Header : 7): verified CRC32 $4EC691C4 +verified CRC32 $A78EB9FA +/dev/disk4 GUID_partition_scheme +/dev/disk4s1 Apple_HFS /Applications/git-annex.upgrade.0 +\"disk4\" unmounted. +\"disk4\" ejected. +git-annex version: 5.20140209-g3a61dbe +build flags: Assistant Webapp Pairing S3 WebDAV FsEvents XMPP 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: 0 1 2 4 +[2014-02-14 12:23:45 CET] main: Upgrading git-annex +[2014-02-14 12:23:45 CET] main: starting assistant version 5.20140209-g3a61dbe +[2014-02-14 12:23:45 CET] UpgradeWatcher: Finished upgrading git-annex to version 5.20140209-g3a61dbe +(scanning...) [2014-02-14 12:23:45 CET] Watcher: Performing startup scan +(started...) +\"\"\"]] +"""]] diff --git a/doc/bugs/Creating_a_box.com_repository_fails/comment_3_6c3610fb95676592f17f36e4e1b09bd8._comment b/doc/bugs/Creating_a_box.com_repository_fails/comment_3_6c3610fb95676592f17f36e4e1b09bd8._comment new file mode 100644 index 000000000..cff2e605d --- /dev/null +++ b/doc/bugs/Creating_a_box.com_repository_fails/comment_3_6c3610fb95676592f17f36e4e1b09bd8._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8" + nickname="Jon Ander" + subject="comment 3" + date="2014-02-11T08:01:47Z" + content=""" +I'm getting the same error in version 5.20140210 +"""]] diff --git a/doc/bugs/Creating_a_box.com_repository_fails/comment_4_c9895712e72854e4b5ff7a58e82ae374._comment b/doc/bugs/Creating_a_box.com_repository_fails/comment_4_c9895712e72854e4b5ff7a58e82ae374._comment new file mode 100644 index 000000000..19350f3e0 --- /dev/null +++ b/doc/bugs/Creating_a_box.com_repository_fails/comment_4_c9895712e72854e4b5ff7a58e82ae374._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk" + nickname="Dorian" + subject="Same problem here" + date="2014-02-12T13:17:50Z" + content=""" +<pre> +[2014-02-12 14:11:12 CET] main: starting assistant version 5.20140127.1 +[2014-02-12 14:11:12 CET] Cronner: You should enable consistency checking to protect your data. +(scanning...) [2014-02-12 14:11:12 CET] Watcher: Performing startup scan +(started...) +(encryption setup) (shared cipher) (testing WebDAV server...) +12/Feb/2014:14:11:49 +0100 [Error#yesod-core] InternalIOException <socket: 112>: hPutBuf: illegal operation (handle is closed) @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5) +(encryption setup) (shared cipher) (testing WebDAV server...) +12/Feb/2014:14:13:01 +0100 [Error#yesod-core] InternalIOException <socket: 116>: hPutBuf: illegal operation (handle is closed) @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5) +</pre> +"""]] diff --git a/doc/bugs/Creating_a_box.com_repository_fails/comment_5_93981afe8162f64ebb9d8c2c6a7ef91e._comment b/doc/bugs/Creating_a_box.com_repository_fails/comment_5_93981afe8162f64ebb9d8c2c6a7ef91e._comment new file mode 100644 index 000000000..bcff92ac9 --- /dev/null +++ b/doc/bugs/Creating_a_box.com_repository_fails/comment_5_93981afe8162f64ebb9d8c2c6a7ef91e._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawk9nck8WX8-ADF3Fdh5vFo4Qrw1I_bJcR8" + nickname="Jon Ander" + subject="Not fixed" + date="2014-02-14T09:03:29Z" + content=""" +This bug has been marked as fixed but I'm still experiencing it in 5.20140210 +"""]] diff --git a/doc/bugs/Creating_a_box.com_repository_fails/comment_6_752b5725b4596721438098d38af8fb66._comment b/doc/bugs/Creating_a_box.com_repository_fails/comment_6_752b5725b4596721438098d38af8fb66._comment new file mode 100644 index 000000000..4804e1671 --- /dev/null +++ b/doc/bugs/Creating_a_box.com_repository_fails/comment_6_752b5725b4596721438098d38af8fb66._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo" + nickname="Dirk" + subject="No working ubuntu package" + date="2014-02-16T20:50:50Z" + content=""" +The 5.20140210 package from François Marier tells me \"WebDAV not supported by this build\" when trying to add a box.com repository. So, can't really test this anymore on ubuntu. +"""]] diff --git a/doc/bugs/In_the_assistant__44___add_some_clarifications_near___34__Add_another_local_repository__34___for_the_case_of_adding_an_existing_repository.mdwn b/doc/bugs/In_the_assistant__44___add_some_clarifications_near___34__Add_another_local_repository__34___for_the_case_of_adding_an_existing_repository.mdwn new file mode 100644 index 000000000..0e49bc368 --- /dev/null +++ b/doc/bugs/In_the_assistant__44___add_some_clarifications_near___34__Add_another_local_repository__34___for_the_case_of_adding_an_existing_repository.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. + +The difference in consequences of `Add another local repository` in the *git-annex assistant* on an existing repository versus on a new directory are unclear. + +### What steps will reproduce the problem? + +Going to the "Add another local repository" in the *git-annex assistant* will make you confused if you want to add an existing repository. + +### What version of git-annex are you using? On what operating system? + +[[!format sh """ +$ git annex version +git-annex version: 5.20140210-gd99db49 +build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA +key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL +remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external +"""]] + +Ubuntu 13.04 + +### Please provide any additional information below. + +Ain't nobody here but us chickens. + +> Ok, I have removed the reference to "new repository" since it can be +> a new or an existing repository. The webapp already asks followup +> questions if the repository exists to make sure nothing confusing +> happens. [[done]] --[[Joey]] diff --git a/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_2_e84b93062c82453f18308a82ee270585._comment b/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_2_e84b93062c82453f18308a82ee270585._comment new file mode 100644 index 000000000..29302f0c1 --- /dev/null +++ b/doc/bugs/Incorrect_symlink_path_in_simple_submodule_use_case/comment_2_e84b93062c82453f18308a82ee270585._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmYwE2LrTHAgbco1mEa_y8rGVqX7exIoxc" + nickname="François" + subject="Replace the gitdir by a symbolic link" + date="2014-02-11T08:06:53Z" + content=""" +chadsgilbert proposed to replace the .git file by a symbolic link: + + <http://stackoverflow.com/a/18238326/1531323> + +What do you think of this possibility? Is it perennial? Can \"git annex init\" do it automatically? + +The [commit message](https://github.com/git/git/commit/69c305178) that introduces the change gives the impression that a symbolic link was a possibility. + +Thanks a lot for git annex! +"""]] diff --git a/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__.mdwn b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__.mdwn new file mode 100644 index 000000000..5de6d2aa5 --- /dev/null +++ b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. + +Joey, it looks like the git version wasn't updated with the latest release as is still too old to respect .gitignore files. I'm hoping that I haven't just made a silly mistake but I don't think I have... + +See http://git-annex.branchable.com/bugs/Mac_OS_git_version_too_old_to_honour_.gitignore/ for bug that was closed. + +### What steps will reproduce the problem? + +Install git-annex 5.20140209-g3a61dbe and try to use .gitignore file to exclude items from git annex. + +### What version of git-annex are you using? On what operating system? + +5.20140209-g3a61dbe on Mac OS 10.9.1. + +### Please provide any additional information below. + +[/Applications/git-annex.app/Contents/MacOS]# ./git annex version + +git-annex version: 5.20140209-g3a61dbe +build flags: Assistant Webapp Pairing S3 WebDAV FsEvents XMPP 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 + +[/Applications/git-annex.app/Contents/MacOS]# ./git --version + +git version 1.8.3.4 (Apple Git-47) + +> Really [[fixed|done]] now. --[[Joey]] diff --git a/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_1_1768ece63499c643c75085773b6d4c18._comment b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_1_1768ece63499c643c75085773b6d4c18._comment new file mode 100644 index 000000000..afa6cc8f6 --- /dev/null +++ b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_1_1768ece63499c643c75085773b6d4c18._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 1" + date="2014-02-20T18:59:44Z" + content=""" +I thought it got upgrades, perhaps it was downgraded again? I have prodded Kevin. +"""]] diff --git a/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_2_888fb193072cf05a34943db072eb7a3b._comment b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_2_888fb193072cf05a34943db072eb7a3b._comment new file mode 100644 index 000000000..1bd1e037e --- /dev/null +++ b/doc/bugs/Mac_OS_git_version_still_too_old_for_.gitignore__63__/comment_2_888fb193072cf05a34943db072eb7a3b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmZgZuUhZlHpd_AbbcixY0QQiutb2I7GWY" + nickname="Jimmy" + subject="comment 2" + date="2014-02-21T07:03:20Z" + content=""" +Thanks Joey and Kevin. Glad to have the bug really fixed and glad to know that I wasn't missing something obvious! +"""]] diff --git a/doc/bugs/Matching_oddity_in_SafeCommand.hs.mdwn b/doc/bugs/Matching_oddity_in_SafeCommand.hs.mdwn new file mode 100644 index 000000000..53bba4a9b --- /dev/null +++ b/doc/bugs/Matching_oddity_in_SafeCommand.hs.mdwn @@ -0,0 +1,28 @@ +In SafeCommand.hs, the code to unwrap a File looks like: + +[[!format haskell """ +toCommand :: [CommandParam] -> [String] +toCommand = concatMap unwrap + where + [...] + -- Files that start with a non-alphanumeric that is not a path + -- separator are modified to avoid the command interpreting them as + -- options or other special constructs. + unwrap (File s@(h:_)) + | isAlphaNum h || h `elem` pathseps = [s] + | otherwise = ["./" ++ s] + unwrap (File s) = [s] + [...] +"""]] + +I am not sure I understand which case would be caught in the last clause "unwrap (File s)". Is that the empty file? Because all non-empty file names seem to have been caught earlier, at least in the "otherwise" if they do not match the condition. In this case, wouldn't it be an error to use an empty file name and wouldn't it be better to throw an exception instead of returning [[]]? + +I would use: + +[[!format haskell """ + unwrap (File []) = throw "Empty file name in SafeCommand.toCommand" +"""]] + +or something similar instead. + +> [[done]] diff --git a/doc/bugs/Matching_oddity_in_SafeCommand.hs/comment_1_1a51630c0791547a7e0b68eea5d81e4c._comment b/doc/bugs/Matching_oddity_in_SafeCommand.hs/comment_1_1a51630c0791547a7e0b68eea5d81e4c._comment new file mode 100644 index 000000000..d52dfed43 --- /dev/null +++ b/doc/bugs/Matching_oddity_in_SafeCommand.hs/comment_1_1a51630c0791547a7e0b68eea5d81e4c._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 1" + date="2014-02-12T16:27:10Z" + content=""" +You're right that line only matches empty filenames. I think that the Hurd actually does support empty filenames. It seems that the command being run would otherwise complain that it was given an empty parameter. So I do not think it's worth throwing an error here. Also, I prefer to keep toCommand a total function. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment new file mode 100644 index 000000000..e3871ea61 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_10_09297f99f3c1c081738ca4ab32808fde._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 10" + date="2014-02-08T18:31:23Z" + content=""" +But you said that setSocketOption failed when you were using XMPP, not when starting the webapp, so I think it's more likely to be one of the setSocketOption calls in the network library, or possibly somewhere else. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment new file mode 100644 index 000000000..78c430533 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_11_1407efc78b92a3c6156154f54e4a14e2._comment @@ -0,0 +1,97 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 11" + date="2014-02-08T19:18:17Z" + content=""" +I honestly have no idea why that move works because + + % ls -lh /usr/lib|grep -E '(gsasl|xml2|gnutls|idn)' + +returns nothing. But couldn't those symbols already be in the other libraries considering, from what I've read at least, haskell stuff are statically compiled by default? + +Anyway, you are completely right that this happened when I try to use XMPP. The reason I was looking in the wrong place to begin with was because the webapp spit out the error messsage. I have redirected my attention to the network library and the xmpp library. + +But I might have found something interesting in the network library. Keep in mind that I just learned a little today, so do correct me if I'm wrong. + +Looking at http://hackage.haskell.org/package/network-2.2.1.8/docs/src/Network-Socket.html I found: + + setSocketOption :: Socket + -> SocketOption -- Option Name + -> Int -- Option Value + -> IO () + setSocketOption (MkSocket s _ _ _ _) so v = do + with (fromIntegral v) $ \ptr_v -> do + throwErrnoIfMinus1_ \"setSocketOption\" $ + c_setsockopt s (socketOptLevel so) (packSocketOption so) ptr_v + (fromIntegral (sizeOf v)) + return () + +Everything here looks good. So I decided to take a look at SocketOption, socketOptLevel and packSocketOption. + + data SocketOption + = DummySocketOption__ + | Debug {- SO_DEBUG -} + | ReuseAddr {- SO_REUSEADDR -} + | Type {- SO_TYPE -} + | SoError {- SO_ERROR -} + | DontRoute {- SO_DONTROUTE -} + | Broadcast {- SO_BROADCAST -} + | SendBuffer {- SO_SNDBUF -} + | RecvBuffer {- SO_RCVBUF -} + | KeepAlive {- SO_KEEPALIVE -} + | OOBInline {- SO_OOBINLINE -} + | TimeToLive {- IP_TTL -} + | MaxSegment {- TCP_MAXSEG -} + | NoDelay {- TCP_NODELAY -} + | Linger {- SO_LINGER -} + | RecvLowWater {- SO_RCVLOWAT -} + | SendLowWater {- SO_SNDLOWAT -} + | RecvTimeOut {- SO_RCVTIMEO -} + | SendTimeOut {- SO_SNDTIMEO -} + + socketOptLevel :: SocketOption -> CInt + socketOptLevel so = + case so of + TimeToLive -> 0 + MaxSegment -> 6 + NoDelay -> 6 + _ -> 1 + + packSocketOption :: SocketOption -> CInt + packSocketOption so = + case so of + Debug -> 1 + ReuseAddr -> 2 + Type -> 3 + SoError -> 4 + DontRoute -> 5 + Broadcast -> 6 + SendBuffer -> 7 + RecvBuffer -> 8 + KeepAlive -> 9 + OOBInline -> 10 + TimeToLive -> 2 + MaxSegment -> 2 + NoDelay -> 1 + Linger -> 13 + RecvLowWater -> 18 + SendLowWater -> 19 + RecvTimeOut -> 20 + SendTimeOut -> 21 + +Everything looks good so I thought long and hard about this. Then, by chance, I just looked at the man page for setsockopt() and it mentioned SOL_SOCKET and I was like \"Hmm...\" + + % grep -R SOL_SOCKET /usr/include + /usr/include/openssl/e_os.h:#define ioctlsocket(a,b,c) setsockopt((a),SOL_SOCKET,(b),(c),sizeof(*(c))) + /usr/include/sys/socket.h:#define SOL_SOCKET 0xffff /* options for socket level */ + /usr/include/sys/socket.h:/* Read using getsockopt() with SOL_SOCKET, SO_PEERCRED */ + +Wat? + + #define SOL_SOCKET 0xffff + +Going back to the Haskell code above I realized that SetSocketOption will NEVER feed 0xffff as level to setsockopt() because socketOptLevel returns 1 unless optname is TimeToLive, MaxSegment or NoDelay. + +Am I way off? +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment new file mode 100644 index 000000000..77c8edc68 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_12_fdec033e37652c51fbcd74438586d285._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 12" + date="2014-02-08T20:03:30Z" + content=""" +WRT haskell static linking, AFAIK that only affects haskell libraries. If they in turn link with C libs, the linking is still dynamic. At least this is the case on both Linux and the limited BSDs I've used it on. Have no OpenBSD experience. + +`SOL_SOCKET` is 1 on linux, so you may have the culprit. + +However.. That's a really old version of network! 2.2.1.8 is from 2010. In a more current 2.4.x version, packSocketOption uses the `SOL_SOCKET` value and not 1, so should work AFAICS. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment new file mode 100644 index 000000000..3981d32bf --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_13_ed3716baf787ca17d227ce2e327a1959._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 13" + date="2014-02-08T20:12:12Z" + content=""" +Does your binary end up dynamically linked to libxml2 etc? If not, it certianly seems plausible that the haskell libs statically linked with the C libs, and then at binary link time it tried to redundantly link with the libs again and failed. If this is the case, it seems it would probably be a bug in ghc. You can use `cabal build --ghc-options=-v` to get a look at how the linker is run. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment new file mode 100644 index 000000000..bb4d095a3 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_14_cf5f92e5cdfc738e7f6178c1d7a73ceb._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 14" + date="2014-02-08T20:29:46Z" + content=""" +Sigh.. Ofcourse it was an old version. It never occurred to me to check that. I was just Googling around and stumbled over that page. +Do you have any pointers on how I would debug this further? + +Regarding the linking; I haven't checked it any further actually. I'm planning on investigating that further once I can get this error sorted out. But my hypothesis is that it's all statically linked all the way through, like I said. That would also explain those error messages I got during linking before. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment new file mode 100644 index 000000000..4aeda69eb --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_15_ad4b7191c9b8f67def33b26a1d762a5d._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 15" + date="2014-02-08T20:56:10Z" + content=""" +I think you need to find which calls to setSocketOption are failing and/or what value is causing the crash. It's a bit of a pain to get a backtrace on error (would need to build everything with profiling enabled and run git-annex with +RTS -xc options). Probably simplest to modify the setSocketOption code: + +[[!format patch \"\"\" +diff --git a/Network/Socket.hsc b/Network/Socket.hsc +index 2fe62ee..0c66432 100644 +--- a/Network/Socket.hsc ++++ b/Network/Socket.hsc +@@ -963,7 +963,7 @@ setSocketOption :: Socket + setSocketOption (MkSocket s _ _ _ _) so v = do + (level, opt) <- packSocketOption' \"setSocketOption\" so + with (fromIntegral v) $ \ptr_v -> do +- throwSocketErrorIfMinus1_ \"setSocketOption\" $ ++ throwSocketErrorIfMinus1_ (\"setSocketOption \" ++ show so ++ \" \" ++ show v) $ + c_setsockopt s level opt ptr_v + (fromIntegral (sizeOf (undefined :: CInt))) + return () +\"\"\"]] + +Which should make it print out a quite nice symbolic name of the option being used on failure, which will make it easy to find any call sites and more importantly, determine what's wrong with that option. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment new file mode 100644 index 000000000..def40653d --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_16_2e765b5286d816bea00880a17a20cbfb._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 16" + date="2014-02-08T21:08:38Z" + content=""" +Thanks for that code snippet! I'll try it out within the next few minutes. + +Also, how would I go about rebuilding everything with profiling support? I'm doing this testing in a virtual machine so I can always start over from scratch. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment new file mode 100644 index 000000000..f36126841 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_17_ded9011dcdbe4de05189a0e8d040f045._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 17" + date="2014-02-08T21:23:02Z" + content=""" +Blow away ~/.ghc and ~/.cabal; cabal update; put `library-profiling: True` in ~/.cabal/config; and reinstall everything. + +Note that you may need to first build ghc's own bundled libraries with profiling support, if your ghc installation does not already include them. I don't know how to do that since on debian I can just `apt-get install ghc-prof`. If that's needed, ghc will tell you and refuse to build stuff with profiling. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment new file mode 100644 index 000000000..d8d73a0b7 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_18_f7a85b46bf7afaaf431d6771219c66b0._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 18" + date="2014-02-08T23:25:29Z" + content=""" +I applied your patch and rebuilt. I even tried doing it from scratch just to get it right. + +I have three news: + +1) I got it completely working in a virtual machine + +2) On my actual (physical) openbsd machine it still isn't working, even though they're almost identical. The only difference is that the physical one also has IPv6 connectivity, while the virtual machine doesn't. Could that be it? I don't know yet, although I'm about to try it. + +3) Your patch did not help. It still didn't print out anything more useful, suggesting that it in fact isn't that function that is throwing the error. [This](http://i.imgur.com/tmBiseE.png) is what the actual error looks like and shows up after I enter the jabber account details. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment new file mode 100644 index 000000000..7ea52c150 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_19_217be2000e423e844241d405ba9f64c8._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 19" + date="2014-02-09T02:13:20Z" + content=""" +I'll bet you didn't rebuild all the libraries that depend on network. (Which all that static linking makes necessary...) + +IPv6 was my first guess; see http://git-annex.branchable.com/bugs/More_build_oddities_under_OpenBSD/#comment-84ee81cd162d22283fcccc1a41c8f8b3 +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment new file mode 100644 index 000000000..29e58e156 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_20_df72e5698ba2bf2eb4fa39c5b2c5be83._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 20" + date="2014-02-20T20:26:03Z" + content=""" +Any further luck on this? + +It would be nice if a page on openbsd could be added to the install page documenting what is needed to get it to build. +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment new file mode 100644 index 000000000..ff76fb3de --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_6_65913a2de8bbe981beaa66c58d2429b5._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 6" + date="2014-02-08T17:23:54Z" + content=""" +Googling around I found [this](http://lpaste.net/77947) codesnippet that suggests setSocketOption is broken under OpenBSD +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment new file mode 100644 index 000000000..72b427357 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_7_8dd46cec230125d1410d8e6824aeddf2._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 7" + date="2014-02-08T17:42:52Z" + content=""" +What was the ugly hack that got it to link? + +I've seen setSocketOption fail on other OS's for various portability reasons. The haskell library that is responsible for this is <http://hackage.haskell.org/package/network>, and you can find several setSocketOption calls in it. I've had good luck ifdefing those out when they don't work. + +Here's a patch where I disable the IPv6Only setting on Android (amoung other unrelated porting) <http://source.git-annex.branchable.com/?p=source.git;a=blob;f=standalone/android/haskell-patches/network_2.4.1.0_0001-android-port-fixes.patch;h=66c0de5448bacaf7449db768b4d720870bbcf9c4;hb=HEAD> +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment new file mode 100644 index 000000000..f7f7e3429 --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_8_275d3e62cb5667a2d6ddd90db7a40bff._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkzwmw_zyMpZC9_J7ey--woeYPoZkAOgGw" + nickname="dxtrish" + subject="comment 8" + date="2014-02-08T18:13:33Z" + content=""" +What I did was to temporarily move away (or rename) the offending libs. What I essentially did was this: + + cabal configure + cabal build + sudo mv /usr/local/lib/lib{xml2,gnutls,gsasl,idn}.a /tmp + cabal install + sudo mv /tmp/lib{xml2,gnutls,gsasl,idn}.a /usr/local/lib + +but I've also had to patch network-info. I've contacted the maintainer of that package but I haven't received anything. I'm considering creating an actual fork with my changes but that would almost seem kind of silly as I don't know *ANY* haskell.. But I am looking at the Haskell wiki as I'm typing this so I can see what I'm looking at :). + +Won't break anything by not setting SO_REUSEADDR? I suspect you're setting it for a reason? +"""]] diff --git a/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment b/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment new file mode 100644 index 000000000..dee77a69f --- /dev/null +++ b/doc/bugs/More_build_oddities_under_OpenBSD/comment_9_ec6a1eb6c7b264c23ec4bbd45465d7d8._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.163" + subject="comment 9" + date="2014-02-08T18:29:41Z" + content=""" +So you moved away libs in /usr/local to expose usable ones in /usr? + +I've had luck before sending the network-info mantainer pull requests: <https://github.com/jystic/network-info/issues/3> + +git-annex does set ReuseAddr in one place; in Utility/Webapp.hs. The only time that would have a benefit would be when using `git annex webapp --listen=address:port` and starting and restarting the webapp. Normally the webapp chooses a random free port so it shouldn't need that. +"""]] diff --git a/doc/bugs/Numcopies_not_checked_when_running_with_--all.mdwn b/doc/bugs/Numcopies_not_checked_when_running_with_--all.mdwn new file mode 100644 index 000000000..e4a364195 --- /dev/null +++ b/doc/bugs/Numcopies_not_checked_when_running_with_--all.mdwn @@ -0,0 +1,40 @@ +### Please describe the problem. +There are a lot of differences in the behaviour of usual commands and commans using --all. +The specific problem I found was that "git annex fsck --all" will only checksum it seems and not report back numcopies failures. +Checking if objects/old versions have propagated is not possible without it or do I miss something. + +(As additional note not sure if related. It seems that git annex fsck --all is running much faster in my tests 1/3 faster. Any reason for that? Bug related?) + + +### What steps will reproduce the problem? +compare "git annex fsck" vs "git annex fsck" (no numcopies check) + +### What version of git-annex are you using? On what operating system? +git-annex version: 5.20140210-gd99db49 +Linux (Ubuntu 13.10) + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +> It's expected that --all (and --unused) make .gitattributes +> annex.numcopies settings be ignored, because with these options git-annex +> is operating on keys, it does not know or care what filename they're +> associated with, and so cannot look them up in .gitattributes. I have +> improved the documentation of .gitattributes files to mention this +> limitation. +> +> I also notice that fsck --all is not checking .git/config's +> annex.numcopies or the new global numcopies setting. It certianly makes +> sense for those numcopies settings to be paid attention to. +> [[fixed|done]] --[[Joey]] +> +> (--all is faster because it can quickly scan through .git/annex/objects +> to find everything, rather than looking at the symlink target of every +> file in the work tree.) diff --git a/doc/bugs/Numcopies_not_checked_when_running_with_--all/comment_1_63af5a11c3ae370433c4bf84de097414._comment b/doc/bugs/Numcopies_not_checked_when_running_with_--all/comment_1_63af5a11c3ae370433c4bf84de097414._comment new file mode 100644 index 000000000..c0cbe3907 --- /dev/null +++ b/doc/bugs/Numcopies_not_checked_when_running_with_--all/comment_1_63af5a11c3ae370433c4bf84de097414._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="stp" + ip="84.56.21.11" + subject="Some suggestions" + date="2014-02-20T21:22:21Z" + content=""" +So I think it should at least for --all look at the global numcopies setting. As this could be essential to prevent data-loss. +I agree that special working tree related numcopies don't need to be included. +"""]] diff --git a/doc/bugs/Resolve_.local_adresses_using_avahi_or_bonjour.mdwn b/doc/bugs/Resolve_.local_adresses_using_avahi_or_bonjour.mdwn index 74966415e..3626f2024 100644 --- a/doc/bugs/Resolve_.local_adresses_using_avahi_or_bonjour.mdwn +++ b/doc/bugs/Resolve_.local_adresses_using_avahi_or_bonjour.mdwn @@ -13,4 +13,4 @@ Ubuntu ### Please provide any additional information below. - +> [[closing|done]] --[[Joey]] diff --git a/doc/bugs/__39__Internal_Server_Error__39___when_creating_repo_on_other_drive_than_C:_on_Windows.mdwn b/doc/bugs/__39__Internal_Server_Error__39___when_creating_repo_on_other_drive_than_C:_on_Windows.mdwn index 42d9ab48b..b6f8e3ca4 100644 --- a/doc/bugs/__39__Internal_Server_Error__39___when_creating_repo_on_other_drive_than_C:_on_Windows.mdwn +++ b/doc/bugs/__39__Internal_Server_Error__39___when_creating_repo_on_other_drive_than_C:_on_Windows.mdwn @@ -31,3 +31,6 @@ Launching web browser on file://C:\Users\bbigras\AppData\Local\Temp\webapp9400.h fatal: Not a git repository: '/annex/.git' error: could not lock config file /annex/.git/config: No such file or directory """]] + +> I've fixed this! [[done]] Yay!! Get the fix from the hourly windows autobuilder. +> --[[Joey]] diff --git a/doc/bugs/assistant_eats_all_CPU/comment_18_970899faca972af6795ae0d3be1ce444._comment b/doc/bugs/assistant_eats_all_CPU/comment_18_970899faca972af6795ae0d3be1ce444._comment new file mode 100644 index 000000000..6e9378154 --- /dev/null +++ b/doc/bugs/assistant_eats_all_CPU/comment_18_970899faca972af6795ae0d3be1ce444._comment @@ -0,0 +1,42 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawm3ayIrWKe5SqLYomXiCL-l2CDpREvA-IE" + nickname="myownlittl" + subject="Seconding this Bug." + date="2014-02-19T02:04:34Z" + content=""" +Hi Joey, I have also experienced this bug. I put my \"~/my\" folder under gitannex's management, and I've since had gitannex's assistant consume a CPU (100% of one core) when starting my computer for 1 - 12 hours (at which point I get impatient and kill annex). If stack traces would help, I can email you those. Unfortunately, my \"my\" folder includes every important document I've created, coded, or needed, in the last six years. It has just under 30,000 files, and probably isn't using gitannex the way it's intended to be used. You can see the distribution of files and file sizes in the tables below. + +If gitannex isn't designed for this sort of use case, can you recommend any free software tools that might be able to help opportunistically keep files in sync at this sort of scale, like GA? + +Thanks for your time, + +Nick + +---- + +[[!table data=\"\"\" +Size<= | Bytes | Count | +0B | 0 | 1108 | +1B | 1 | 264 | +16B | 16 | 179 | +256B | 256 | 3414 | +4K | 4096 | 12771 | +65K | 65536 | 7402 | +1M | 1048576 | 2975 | +16M | 16777216 | 703 | +256M | 268435456 | 126 | +4G | 4294967296 | 5 | +\"\"\"]] + + | Size<= | Bytes | Count | + | 0B | 0 | 1108 | + | 1B | 1 | 264 | + | 16B | 16 | 179 | + | 256B | 256 | 3414 | + | 4K | 4096 | 12771 | + | 65K | 65536 | 7402 | + | 1M | 1048576 | 2975 | + | 16M | 16777216 | 703 | + | 256M | 268435456 | 126 | + | 4G | 4294967296 | 5 | +"""]] diff --git a/doc/bugs/assistant_on_windows_adding_remote_containing_linux_paths.mdwn b/doc/bugs/assistant_on_windows_adding_remote_containing_linux_paths.mdwn index cdaabf78e..c6b6ee482 100644 --- a/doc/bugs/assistant_on_windows_adding_remote_containing_linux_paths.mdwn +++ b/doc/bugs/assistant_on_windows_adding_remote_containing_linux_paths.mdwn @@ -6,9 +6,18 @@ internal error, /home/michele/assistannex is not absolute ### What steps will reproduce the problem? -create a transfer repository on a usb drive (from windows) merge it with a repository on linux, try to merge it on another target windows machine +create a transfer repository on a usb drive (from windows) merge it with a +repository on linux, try to merge it on another target windows machine ### What version of git-annex are you using? On what operating system? git-annex version 5.20140128-g29aea74 +> I'm not able to follow the steps to reproduce this, but I think +> I see what the problem is. `isAbsolute` on windows does not think that +> unix-style path is absolute. Such a path can appear in a remote of a git +> repository, particularly if part of that repository was set up on a +> non-Windows system. While the remote won't be usable on Windows with a +> path like that, git-annex should not choke on the path either. +> I have fixed the code to deal with this. +> [[done]] --[[Joey]] diff --git a/doc/bugs/assistant_unable_to_auth___40__windows__41__.mdwn b/doc/bugs/assistant_unable_to_auth___40__windows__41__.mdwn index 494e4fb58..b019d51b8 100644 --- a/doc/bugs/assistant_unable_to_auth___40__windows__41__.mdwn +++ b/doc/bugs/assistant_unable_to_auth___40__windows__41__.mdwn @@ -81,3 +81,5 @@ Options: -q --quiet avoid verbose output etc """]] + +> [[fixed|done]]; both for regular remote ssh servers, and for rsync.net --[[Joey]] diff --git a/doc/bugs/assistant_using_the_incorrect_path_on_windows__63__.mdwn b/doc/bugs/assistant_using_the_incorrect_path_on_windows__63__.mdwn index 387ba7416..1ad800522 100644 --- a/doc/bugs/assistant_using_the_incorrect_path_on_windows__63__.mdwn +++ b/doc/bugs/assistant_using_the_incorrect_path_on_windows__63__.mdwn @@ -40,3 +40,6 @@ Start creating a remote repository. ### What version of git-annex are you using? On what operating system? Windows 7, git-annex version 5.20131230-g192d991 + +> [[fixed|done]]; git-annex now ensures HOME is set when running cygwin +> commands that require it. --[[Joey]] diff --git a/doc/bugs/can__39__t_drop_unused_files_that_never_were_added.mdwn b/doc/bugs/can__39__t_drop_unused_files_that_never_were_added.mdwn new file mode 100644 index 000000000..361f21f0e --- /dev/null +++ b/doc/bugs/can__39__t_drop_unused_files_that_never_were_added.mdwn @@ -0,0 +1,86 @@ +### Please describe the problem. + +When adding files to the annex and then deciding against it in an "unusual" way, git-annex gets confused and the file left behind can't be removed from the annex... + +### What steps will reproduce the problem? + +1. Add file with "git annex add" +2. Decide you don't need the file add all +3. "git rm -f newfile" +4. "git annex unused" +5. "git annex dropunused all" + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20140210 on Debian unstable + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log +$ git init +Initialized empty Git repository in /tmp/foo/.git/ +$ ls -l +total 0 +$ cp ~/download/hub-ctrl.c . +$ git add hub-ctrl.c +$ git commit +[master (root-commit) ed7eb68] A file. + 1 file changed, 412 insertions(+) + create mode 100644 hub-ctrl.c +$ cp ~/download/hub-ctrl . +$ ls -l +total 28 +-rwxr-xr-x 1 tobias tobias 14130 Feb 19 00:49 hub-ctrl +-rw-r--r-- 1 tobias tobias 9270 Feb 19 00:48 hub-ctrl.c +$ git annex init +init ok +(Recording state in git...) +$ git annex add +add hub-ctrl ok +(Recording state in git...) +$ git status +On branch master +Changes to be committed: + (use "git reset HEAD <file>..." to unstage) + + new file: hub-ctrl + +$ git rm hub-ctrl +error: the following file has changes staged in the index: + hub-ctrl +(use --cached to keep the file, or -f to force removal) +$ git rm -f hub-ctrl +rm 'hub-ctrl' +$ git status +On branch master +nothing to commit, working directory clean +$ git annex unused +unused . (checking for unused data...) (checking HEAD...) + Some annexed data is no longer used by any files: + NUMBER KEY + 1 SHA256E-s14130--d4e777ba2b99ed0a520fbabe7b93cf2165373b4945afe8dcb626231d9051f19d + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused NUMBER + +ok +$ git annex dropunused all +dropunused 1 (unsafe) + Could only verify the existence of 0 out of 1 necessary copies + + Rather than dropping this file, try using: git annex move + + (Use --force to override this check, or adjust numcopies.) +failed +git-annex: dropunused: 1 failed +$ + +# End of transcript or log. +"""]] + +> It seems to me that if you run `git annex dropunused --force`, it will +> remove the file. This needing --force is a recent change; git-annex +> tries to never posibly lose data unless forced. Dropping the last +> copy of a file certianly qualifies. [[done]] --[[Joey]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn new file mode 100644 index 000000000..68328ac96 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn @@ -0,0 +1,48 @@ +[[!format sh """ +greg@x200s:~/Documents$ git-annex unused +unused . (checking for unused data...) (checking annex/direct/master...) (checking synced/annex/direct/master...) (checking synology/master...) + Some annexed data is no longer used by any files: + NUMBER KEY + 1 SHA256E-s16367--0b00ef0154c42a0bf94e5be8d92d8af27455d59794f26c33dfc39c09178521c9.pdf + 2 SHA256E-s84--b08e1c831863bb43c02158bd5e8f3f5416c3a5203d89fa94a22149460142c273.odt + 3 SHA256E-s84--ec4caae451180a29721f2b6667eec8ec80eaa724f0727cf99d2bb21bf9218e9d.odt + ... + 88 SHA256E-s84--710d69bef61674b04974ac550d713e5928563b2a12b902b64fe451705b967452.doc + 89 SHA256E-s3830--1348d6248e35625da3e22f73d2a0017185bb5e1aa37f65bbca5dfcb3c7f53034 + 90 SHA256E-s119822--7c1b53ab6402b8835473f0b5c326f3cc300ac9372be79694942c1efa4bcdc621.pdf + 91 SHA256E-s84--63b6188696795885ff6570a76a3a74799396787f7058cbcfd4a2c40b22982420.odt + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused NUMBER + +ok +greg@x200s:~/Documents$ git-annex copy --unused --to synology +"""]] + +Is that correct behavior? I would assume the last command would at least run through the 91 files and check my synology remote that they are there. Like this repo did: + +[[!format sh """ +$ git-annex unused +unused . (checking for unused data...) (checking master...) (checking 60justin/master...) + Some annexed data is no longer used by any files: + NUMBER KEY + 1 SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF + 2 SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF + 3 SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF + 4 SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG + 5 SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG + 6 SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused NUMBER + +ok +$ git-annex copy --unused --to synology +copy SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF (checking synology...) ok +copy SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF (checking synology...) ok +copy SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF (checking synology...) ok +copy SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG (checking synology...) ok +copy SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG (checking synology...) ok +copy SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG (checking synology...) ok +$ +"""]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment new file mode 100644 index 000000000..cedc0f7f9 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://grossmeier.net/" + nickname="greg" + subject="indirect vs direct" + date="2014-02-20T06:25:31Z" + content=""" +Aha! The issue is that the first repo (the one not copying unused files to synology) was in direct mode. I switched it to indirect and not only are there now a lot more files listed in unused, but copy --unused is working as expected. + +Should there be a warning in git-annex unused when in direct mode about this? I'm not exactly sure what is happening (not sure why the number of unused would go up from 91 to 296). +"""]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_2_15559ba19393f5c061f77bc56379f8e1._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_2_15559ba19393f5c061f77bc56379f8e1._comment new file mode 100644 index 000000000..a3a3c119f --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_2_15559ba19393f5c061f77bc56379f8e1._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="Could I get a "version", brethren?" + date="2014-02-20T17:58:32Z" + content=""" +I think there are two bugs here. I just reproduced and fixed a bug that would caused `git annex unused` to sometimes not notice certain unused keys when in direct mode. That's why the number you were finding in direct and indirect was different. + +That does not explain why `copy --unused` would not operate on unused files when in direct mode. A problem I have not managed to reproduce.. + +There was a recent change to the format of the .git/annex/unused.log, which temporarily broke reading it (fixed in 5.20140210). This could be some version skew problem, as while the new git-annex version can read the old log format, the old git-annex version will ignore the new log format. +"""]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment new file mode 100644 index 000000000..4fb2b3d39 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://grossmeier.net/" + nickname="greg" + subject="comment 3" + date="2014-02-20T19:31:56Z" + content=""" +heh, I *just* dist-upgraded this morning on the box that was showing the problem from git-annex_5.20140127_amd64.deb to git-annex_5.20140210_amd64.deb. So what you say is probably right (re unused.log). + +The only other annex I have in direct mode right now is one that I also am using the standalone build with (version 5.20131224-g6ca5271 right now). It has unused content in it (in fact, it's the synology annex, where I'm moving all the unused data to). I can do testing there if needed (and since it's a standalone build, it's easy for me to switch around git-annex versions with symlinks). The only problem is that it is dog slow when running git-annex unused. :) +"""]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_4_b88530080fd90686cfa7e336f8328dcb._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_4_b88530080fd90686cfa7e336f8328dcb._comment new file mode 100644 index 000000000..9deb87d24 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_4_b88530080fd90686cfa7e336f8328dcb._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 4" + date="2014-02-20T19:49:21Z" + content=""" +Well, if you had a newer git-annex than 5.20140127 temporarily in path, it would certianly explain it. I have tested --unused in direct mode and am not seeing any problems. +"""]] diff --git a/doc/bugs/fsck_giving_false_checking_information.mdwn b/doc/bugs/fsck_giving_false_checking_information.mdwn new file mode 100644 index 000000000..b22ac1c66 --- /dev/null +++ b/doc/bugs/fsck_giving_false_checking_information.mdwn @@ -0,0 +1,29 @@ +### Please describe the problem. +When a repository has no object of a given file and git annex fsck is run it still shows "fsck file ok", which is missleading in the sense, that it gives the impression that it checked the file is alright/checksummed. + +As a result of this it seems that incremental fscks are not incremental with non checkable objects. On each run (after the first one) with "git annex fsck --incremental --more --schedule-limit 1d" all files without objects are checked even so it should wait another day till it checks again. + +Probably best to say checksum couldn't be checked on x files (only give that as quiet output, not every check) + +Another thing, which came up as a problem was, that checksum fsck would not be wanted to run as often as numcopie checks. +When the incremental fsck is used to check for bad files "git annex fsck --incremental --more --limit 1m" after a fast numcopies check "git annex fsck --incremental --more --limit 1m fast" it messes up the actual bad files check. +As both are currently using the same incremental "lock"-file they are colliding. + +### What steps will reproduce the problem? +- + +### What version of git-annex are you using? On what operating system? +git-annex version: 5.20140210-gd99db49 +Linux (Ubuntu 13.10) + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment b/doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment new file mode 100644 index 000000000..af198c722 --- /dev/null +++ b/doc/bugs/fsck_giving_false_checking_information/comment_1_1000603ea6b8a19eb09e6754789ad528._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="stp" + ip="188.193.207.34" + subject="Earlier version syntax was removed" + date="2014-02-17T16:05:34Z" + content=""" +In earlier versions I noticed that when checksumming it would give back \"fsck file (checksum...) ok\" instead of \"fsck file ok\", which is at least better than not differentiating. This should definitely be improved. Perhaps even clearer than the (checksum...) notice. + +But still the incremental run not being incremental and not taking into account the schedule-limit seems strange. +"""]] diff --git a/doc/bugs/fsck_giving_false_checking_information/comment_2_3ce7c8f7098f0bf86ed409a3a095c152._comment b/doc/bugs/fsck_giving_false_checking_information/comment_2_3ce7c8f7098f0bf86ed409a3a095c152._comment new file mode 100644 index 000000000..838471598 --- /dev/null +++ b/doc/bugs/fsck_giving_false_checking_information/comment_2_3ce7c8f7098f0bf86ed409a3a095c152._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 2" + date="2014-02-20T20:11:36Z" + content=""" +You're only meant to use one of --incremental, or --more, or --incremental-schedule at a time. I have made fsck refuse to accept combinations of those options. + +What was happening is that, since you didn't understand the documentation (which is possibly not as clear as it could be; I have tried to improve it now), the --incremental option you passed dominated all the other options, and made it start a *new* incremental fsck each time. Which means it started from the beginning and fscked every file until you stopped it. + +I agree that it would be better if fsck --fast --incremental did not collide with fsck --incremental. There is already a bug about that: [[incremental fsck should not use sticky bit]]. + +Finally, I agree that losing the \"(checksum)\" made fsck output less informative. Although I don't think it is needed in the `git annex add` output. I have made it be shown in only the fsck output. +"""]] diff --git a/doc/bugs/fsck_giving_false_checking_information/comment_3_be4d0fec56c29cf978ef7d1715eaa516._comment b/doc/bugs/fsck_giving_false_checking_information/comment_3_be4d0fec56c29cf978ef7d1715eaa516._comment new file mode 100644 index 000000000..27de72358 --- /dev/null +++ b/doc/bugs/fsck_giving_false_checking_information/comment_3_be4d0fec56c29cf978ef7d1715eaa516._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="stp" + ip="84.56.21.11" + subject="Great improvements" + date="2014-02-20T21:20:15Z" + content=""" +Thanks for clearing it up. It is still a bit confusing that you have to differentiate on the second run. (using --more) I probably view it as inconvenient as it make me have to remember the first and second time of running a command. I think it would be cleaner to have \"--incremental\" always skipping files and \"--incremental restart\" start from the beginning. + +Ah great yeah they are different functions and should therefore not interfere. (fsck --fast --incremental) + +Great that the checksum is back in and yeah I agree that it isn't really needed in the add command. + + +"""]] diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn new file mode 100644 index 000000000..a9426724c --- /dev/null +++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects.mdwn @@ -0,0 +1,31 @@ +### Please describe the problem. +When "git annex sync --content" is used only objects currently in the working tree are synced. It doesn't honor full archives, which should get all objects. +So only objects similar to "git annex find --want-get" are synced and not every available object "git annex get --all" + + +### What steps will reproduce the problem? +# mein repo: +git annex add file +git annex sync +git annex rm file +git annex sync + +# other repo: +git annex wanted here "not copies=backup:3" +git annex find --want-get # will be empty +git annex sync --content # nothing is synced even so all files should be backed up +git annex get --all # will sync the object from file + +### What version of git-annex are you using? On what operating system? +git-annex version: 5.20140210-gd99db49 +Linux (Ubuntu 13.10) + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment new file mode 100644 index 000000000..e395eac0e --- /dev/null +++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 1" + date="2014-02-20T19:34:29Z" + content=""" +Yep, sync --content only looks at the work tree. + +I suppose that the assistant does a better job in this situation, since if it cannot access an archive repo, it will remember that it tried to send a file to it, and retry that transfer later -- even if in the meantime the file has gotten deleted out of the work tree (and still has content present, due to using indirect mode). I'm actually not 100% sure .. the assistant may give up on transferring a file if it's gotten removed from the work tree. It's worth considering this because I basically want sync --content to do the same syncing that the assistant does. + +Anyway, sync --content could certianly look at all keys present in the annex. This would require a separate pass, and it might then try to upload a key twice, once from work tree, and once from annex, and fail twice. + +Maybe it would be better to have this as a separate --content --all. It might also make sense to keep sync --content only looking at the work tree by default to support cases where there are multiple branches and you only want to sync one. + +I think this needs more thought. +"""]] diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment new file mode 100644 index 000000000..4560e10d9 --- /dev/null +++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_2_70804d50b07630fadfc029a22173c5a0._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="stp" + ip="84.56.21.11" + subject="Some ideas for content sync" + date="2014-02-20T21:18:30Z" + content=""" +I agree that it is a tricky situation. The main issue I have is that archive preferred content expressions indicates that all versions are transferred, but when you (worst case) migrate full archives to other disks and just use git annex sync --content, you would loose all objects. + +I like the idea of --content --all as this would be consistent with other commands such as fsck for example. +Still it seems with preferred content expressions only applying to working tree data that it would still miss \"copies=backup:2\" for example and only use working tree files. Which is misleading and could lead to dataloss in my opinion. + +So the best would probably be to let preferred content for number of copies at least work on all objects, either per default or when \"git annex sync --content --all\" is used. You wouldn't run that on usual repos, but definitely on backup, archive or similar repos. + +"""]] diff --git a/doc/bugs/git_repo_fails_to_checkout.mdwn b/doc/bugs/git_repo_fails_to_checkout.mdwn new file mode 100644 index 000000000..0c3b66018 --- /dev/null +++ b/doc/bugs/git_repo_fails_to_checkout.mdwn @@ -0,0 +1,39 @@ +### Please describe the problem. + +Attempting to clone the git repository produces + + (master) cayley:git-annex% git checkout -f HEAD + error: unable to create file doc/bugs/fatal:_unable_to_access___39__..__47__..__47__..__47__..__47__C:__92__Users__92____91__...__93____92__annex__92__.git__47__config__39__:_Invalid_argument___40__Windows__41__.mdwn (File name too long) + fatal: cannot create directory at 'doc/bugs/fatal:_unable_to_access___39__..__47__..__47__..__47__..__47__C:__92__Users__92____91__...__93____92__annex__92__.git__47__config__39__:_Invalid_argument___40__Windows__41__': File name too long + +### What steps will reproduce the problem? + +I get the above with either + + git clone https://github.com/joeyh/git-annex + +or (after this fails) retrying with + + cd git-annex + git checkout -f HEAD + +### What version of git-annex are you using? On what operating system? + +I am running git 1.9.0 from git (5f95c9f850b19b368c43ae399cc831b17a26a5ac in the git git repo) on Ubuntu 13.04. + +> More encfs brain-damange. + + One such limitation is filename length. If your underlying + filesystem limits you to N characters in a filename, then + EncFS will limit you to approximately 3*(N-2)/4. + +> It's really astounding that Ubuntu inflicts that POS on users. +> However, I can't see that as justification for limiting the +> git-annex repository to filenames shorter than `PATH_MAX` -- just +> as DOS's problems with both filename length and also `:` in filenames +> is not a good reason to mangle the repository. +> +> In either case, it's up to the user to find a way to make it work. +> In the DOS case, that involves using Cygwin's git. In the encfs case, +> it presumably means checking it out into a real filesystem. +> [[done]] --[[Joey]] diff --git a/doc/bugs/git_repo_fails_to_checkout/comment_1_d92e7e3b41382501a08f6a66c673b1fd._comment b/doc/bugs/git_repo_fails_to_checkout/comment_1_d92e7e3b41382501a08f6a66c673b1fd._comment new file mode 100644 index 000000000..55e063f39 --- /dev/null +++ b/doc/bugs/git_repo_fails_to_checkout/comment_1_d92e7e3b41382501a08f6a66c673b1fd._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://geoffreyirving.myopenid.com/" + nickname="Geoffrey Irving" + subject="encrypted home directory" + date="2014-02-18T18:05:24Z" + content=""" +It looks like this problem is related to using an encrypted home directory. +"""]] diff --git a/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_6_c7f1170b84f9ea4befe96cdfe3bdaa1f._comment b/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_6_c7f1170b84f9ea4befe96cdfe3bdaa1f._comment new file mode 100644 index 000000000..9d70c84ec --- /dev/null +++ b/doc/bugs/incremental_fsck_should_not_use_sticky_bit/comment_6_c7f1170b84f9ea4befe96cdfe3bdaa1f._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.172" + subject="comment 6" + date="2014-02-20T20:09:22Z" + content=""" +I also need some local fast database for metadata index storing. +"""]] diff --git a/doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn b/doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn new file mode 100644 index 000000000..12e2672f3 --- /dev/null +++ b/doc/bugs/numcopies_deprecated__44___but_still_in_walkthrough.mdwn @@ -0,0 +1,21 @@ +### Please describe the problem. +Within the walkthrough the deprecated annex.numcopies are still used. At least it should be added that "git annex numcopies x" can be used to define it globally without the need for a .gitattribute file. And use .gitattribute only for per directory and fine grained control. +http://git-annex.branchable.com/walkthrough/backups/ + +### What steps will reproduce the problem? + + +### What version of git-annex are you using? On what operating system? + + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/problems_with_android_and_gpg.mdwn b/doc/bugs/problems_with_android_and_gpg.mdwn new file mode 100644 index 000000000..ac5cab7cd --- /dev/null +++ b/doc/bugs/problems_with_android_and_gpg.mdwn @@ -0,0 +1,73 @@ +### Please describe the problem. +When my android phone tries to decode files downloaded from a ssh remote using shared encryption, gpg errors occur. + +### What steps will reproduce the problem? +Setup is very similar to my other bug report in <https://git-annex.branchable.com/bugs/problems_with_android_and_xmpp/>. +Only difference is the location of the annex on the android side. +I have put it on the /data mount which uses ext4 to avoid the /sdcard fuse mount, which does not handle symlinks. + +1) setup git annex via webapp on laptop: + +* local annex + +* remote annex via ssh with shared encryption (tried two different servers, one with and one without git-annex installed) + +* share with my devices using jabber.me account + +2) setup git annex via webapp on android: + +* local annex in /data/data/ga.androidterm/annex (ext filesystem) + +* share with my devices using jabber.me account + +* ssh remote is automatically added via XMPP + +3) add file to annex on linux, which gets uploaded to the ssh remote + +4) symlink for file is created on phone and data downloaded, but never decrypted (see logs below) + +### What version of git-annex are you using? On what operating system? +Ubunut Linux 12.04 with git-annex version: + +* 5.20140127.1 (from PPA) + +Android 4.2 (rooted) with git-annex version: + +* 5.20140211-g556cfeb (from autobuilds) + +### Please provide any additional information below. +full logs: + +* linux: <http://pastebin.ca/2639929> + +* android: <http://pastebin.ca/2639945> + +most interesting parts: +[[!format sh """ +# +# android: +# +gpg: can't open `/usr/local/share/gnupg/options.skel': No such file or directory +gpg: DBG: locking for `/sdcard/git-annex.home/.gnupg/secring.gpg.lock' done via O_EXCL +gpg: DBG: locking for `/sdcard/git-annex.home/.gnupg/pubring.gpg.lock' done via O_EXCL +gpg: decryption failed: bad key + +# followed by just the last line for all further attemps +gpg: decryption failed: bad key + +# gpg it self seems to be fine +root@android:/data/data/ga.androidterm # ./bin/gpg --version -v +gpg (GnuPG) 1.4.15 +Copyright (C) 2013 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. + +Home: ~/.gnupg +Supported algorithms: +Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA +Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, + CAMELLIA128, CAMELLIA192, CAMELLIA256 +Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 +Compression: Uncompressed, ZIP, ZLIB +"""]] diff --git a/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment b/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment new file mode 100644 index 000000000..308d7ed8d --- /dev/null +++ b/doc/bugs/problems_with_android_and_gpg/comment_1_526d8805cb1ae896e8b1920ac2aecc17._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://openid.stackexchange.com/user/3f8a1927-744c-4409-8425-48fb3c86672f" + nickname="kim" + subject="comment 1" + date="2014-02-14T19:16:02Z" + content=""" +I am experiencing the exaxact same issue on android 4.3 with the current git-annex version (5.20140211) +"""]] diff --git a/doc/bugs/problems_with_android_and_xmpp.mdwn b/doc/bugs/problems_with_android_and_xmpp.mdwn new file mode 100644 index 000000000..0b05c94bb --- /dev/null +++ b/doc/bugs/problems_with_android_and_xmpp.mdwn @@ -0,0 +1,82 @@ +### Please describe the problem. +When trying to sync my android phone with my linux laptop using the git annex assistant and XMPP no files are transferred. + +### What steps will reproduce the problem? +1) setup git annex via webapp on laptop: + +* local annex + +* remote annex via ssh with shared encryption (tried two different servers, one with and one without git-annex installed) + +* share with my devices using jabber.me account + +2) setup git annex via webapp on android: + +* local annex in /sdcard/annex (fuse filesystem without symlink support) + +* share with my devices using jabber.me account + +* ssh remote is automatically added via XMPP + +3) add files to annex on linux, they get uploaded to the ssh remote + +4) wait forever for any files from linux to download to phone + +5) add files to annex on phone, they get uploaded to the ssh remote + +4) wait forever for any files from phone to download to linux + +### What version of git-annex are you using? On what operating system? +Ubunut Linux 12.04 with git-annex version: + +* 5.20140127.1 (from PPA) + +Android 4.2 (rooted) tried with git-annex versions: + +* 5.20140209 (from http://downloads.kitenet.net/git-annex/android/current/4.0/) + +* 5.20140211-g556cfeb (from autobuilds) + +### Please provide any additional information below. +full logs: + +(these do not show the uploads to the ssh remote, because I restarted to get clean and short logs, but the files are on the server and can be dropped and restored on the linux side manually) + +* linux: <http://pastebin.ca/2639948> + +* android: <http://pastebin.ca/2639952> + +most interesting parts: +[[!format sh """ +# +# linux: +# + +[2014-02-13 13:11:27 CET] XMPPClient: Pairing with dorian in progress +[2014-02-13 13:11:28 CET] XMPPSendPack: Syncing with dorian +To xmpp::dorian@jabber.me + * [new branch] git-annex -> refs/synced/4ce7576f-6f02-4657-bab5-2f4c4a564ee7/ZG9yaWFuQGphYmJlci5tZQ==/git-annex + * [new branch] annex/direct/master -> refs/synced/4ce7576f-6f02-4657-bab5-2f4c4a564ee7/ZG9yaWFuQGphYmJlci5tZQ==/annex/direct/master +[2014-02-13 13:11:29 CET] XMPPSendPack: Syncing with dorian +Everything up-to-date +[2014-02-13 13:12:21 CET] XMPPSendPack: Syncing with dorian +Everything up-to-date +[2014-02-13 13:12:21 CET] XMPPSendPack: Syncing with dorian +fatal: Could not read from remote repository. + +Please make sure you have the correct access rights +and the repository exists. + +# +# android: +# +[2014-02-13 13:16:25 CET] XMPPClient: sending: Pushing "d29" (ReceivePackOutput 2 "<elided>") +[2014-02-13 13:16:25 CET] XMPPClient: to client: d6/tigase-14134 +[2014-02-13 13:18:22 CET] XMPPClient: received: ["Unknown message"] +[2014-02-13 13:18:25 CET] XMPPReceivePack: timeout waiting for git send-pack output via XMPP +fatal: The remote end hung up unexpectedly +[2014-02-13 13:18:25 CET] XMPPReceivePack: finished running push Pushing "d29" (StartingPush (UUID "4ce7576f-6f02-4657-bab5-2f4c4a564ee7")) True +[2014-02-13 13:18:25 CET] XMPPClient: sending: Pushing "d29" (ReceivePackDone (ExitFailure 128)) +[2014-02-13 13:18:25 CET] XMPPClient: to client: d6/tigase-14134 + +"""]] diff --git a/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment b/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment new file mode 100644 index 000000000..945a59021 --- /dev/null +++ b/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk" + nickname="Dorian" + subject="further information" + date="2014-02-13T13:33:49Z" + content=""" +I just tried moving the annex on the android phone to a different location, because I wasn't sure how git annex handles the /sdcard's fuse file system without symlinks... +So with the annex on the /data mount using ext I got a little further (and discovered a different problem <https://git-annex.branchable.com/bugs/problems_with_android_and_gpg/>). + + +"""]] diff --git a/doc/bugs/rsync_transport:_username_not_respected.mdwn b/doc/bugs/rsync_transport:_username_not_respected.mdwn new file mode 100644 index 000000000..467e67643 --- /dev/null +++ b/doc/bugs/rsync_transport:_username_not_respected.mdwn @@ -0,0 +1,43 @@ +### Please describe the problem. + +I created an encrypted rsync remote with a username (user@host). The rsync command issued by git-annex doesn't contain the username. I solved the problem using .ssh/config. + +### What steps will reproduce the problem? + + +[[!format sh """ +# Add remote like that +git-annex initremote encrsync type=rsync rsyncurl=user@xxx.rsync.net:rsync/X keyid=0xXXX +# Sync it +git-annex sync --content + + +# You'll see +$> ps ax | grep rsync +30652 pts/3 S+ 0:00 /home/ganwell/bin/git-annex.linux//lib64/ld-linux-x86-64.so.2 --library-path /home/ganwell/bin/git-annex.linux//etc/ld.so.conf.d:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu/libc:/home/ganwell/bin/git-annex.linux//usr/lib:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu:/home/ganwell/bin/git-annex.linux//lib64:/home/ganwell/bin/git-annex.linux//lib/x86_64-linux-gnu: /home/ganwell/bin/git-annex.linux/shimmed/rsync/rsync xxx.rsync.net:rsync/X/9fa/634/'GPGHMACSHA1--X/GPGHMACSHA1--X +"""]] + + + +### What version of git-annex are you using? On what operating system? + +OS: Linux + +Ver: git-annex version: 5.20140210-g1e0a3ad + +Type: prebuilt + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +> Argh! How did that break? I know it used to work. +> I have fixed it, unfortunately the fix was too late for today's release, +> but it will be available in autobuilds shortly. +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/trust_command_and_gitconfig_contradiction_causing_confusion.mdwn b/doc/bugs/trust_command_and_gitconfig_contradiction_causing_confusion.mdwn new file mode 100644 index 000000000..d67ebe66a --- /dev/null +++ b/doc/bugs/trust_command_and_gitconfig_contradiction_causing_confusion.mdwn @@ -0,0 +1,35 @@ +### Please describe the problem. +'trust', 'dead', etc commands completing with 'ok' but fail to acknowledge contradiction in .git/config, causing confusion. + +[[!format sh """ +greg@x200s:~/Photos$ git-annex untrust home # yes, bad remote name +untrust home ok +(Recording state in git...) +greg@x200s:~/Photos$ git-annex status # /me is old-school and forgets +greg@x200s:~/Photos$ git-annex info +repository mode: indirect +trusted repositories: 2 + c0e4106e-2631-11e2-9749-1bfa37a61069 -- rose + c69d6fcc-18d1-11e2-9487-2fe6dbf0516b -- home (photos on eeepc) + +.... + +greg@x200s:~/Photos$ git-annex dead home +dead home ok +(Recording state in git...) +greg@x200s:~/Photos$ git-annex info +repository mode: indirect +trusted repositories: 2 + c0e4106e-2631-11e2-9749-1bfa37a61069 -- rose + c69d6fcc-18d1-11e2-9487-2fe6dbf0516b -- home (photos on eeepc) +"""]] + +The home remote has "annex-trustlevel=trusted" in .git/config + + +Maybe have those commands instead say "Hey, this is different than what you said explicitly in .git/config, ya sure? (y/n)" If y, overwrite config, if n, abort. + +### What version of git-annex are you using? On what operating system? +5.20140127 on Debian + +> [[Fixed|done]], it will now warn about this situation. --[[Joey]] |