diff options
Diffstat (limited to 'doc/bugs')
73 files changed, 1921 insertions, 3 deletions
diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn index 6cca0082c..ae1f7c522 100644 --- a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn +++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows.mdwn @@ -1,3 +1,5 @@ Having a windows build of Git-Annex in an archived format would be very usefull for automation, and deploy. Could it be possible to add this to the buildserver of gitannex? +[[!tag moreinfo]] + diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment new file mode 100644 index 000000000..3bd7381e1 --- /dev/null +++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_1_70480ffd417788f18cd75a9b625ecf3b._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-11-16T18:41:25Z" + content=""" +It would be helpful to have more details, such as an example of software +distributed for windows that way, or documentation of how such an archive +is used on windows. + +The git-annex Windows installer is a exe file that uses the NullSoft +installation system. As far as I know that's pretty common in the Windows +world. + +I don't see any point in zipping up the single exe. It would be possible to +make a zip containing all the files that instlling the exe installs. But, +the installation process has to integrate git-annex with git, it installs +menu items, etc. A zip file would not be able to handle that integration. +So its use seems limited to me. +"""]] diff --git a/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment new file mode 100644 index 000000000..b0db54479 --- /dev/null +++ b/doc/bugs/Adding_zip_or_7z_or_tar_archive_builds_for_windows/comment_2_afa6a131999feda67876859cd85ebcfc._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="luckcolorsgoo@ab4f3c1c44a7dbcbcb9d9a29315b59ad524ceaaa" + nickname="luckcolorsgoo" + avatar="http://cdn.libravatar.org/avatar/ddff84cd2a97252a05cccb4bc5010448" + subject="comment 2" + date="2016-11-16T22:56:46Z" + content=""" +In my case i was going to make a script for automatically downloading and updating an git portbale / git annex instance, by first fetching git portbale and then downloading the gitannex exe. + +So yeah it's more reliable to extract an archive rather than trying to extract the setup without executing it. +That's why i'm asking for this feature. :) + + + +"""]] diff --git a/doc/bugs/Allow_automatic_retry_git_annex_get.mdwn b/doc/bugs/Allow_automatic_retry_git_annex_get.mdwn index 0e85b7acf..c6e406b49 100644 --- a/doc/bugs/Allow_automatic_retry_git_annex_get.mdwn +++ b/doc/bugs/Allow_automatic_retry_git_annex_get.mdwn @@ -59,5 +59,3 @@ SHA256E-s41311329--69c3b054a3fe9676133605730d85b7fcef8696f6782d402a524e41b836253 [[!meta title="Detect stalled transfer and retry or abort it"]] - -> [[done]] --[[Joey]] diff --git a/doc/bugs/Allow_automatic_retry_git_annex_get/comment_4_899b66a20b8e29a23068d249a461c19f._comment b/doc/bugs/Allow_automatic_retry_git_annex_get/comment_4_899b66a20b8e29a23068d249a461c19f._comment new file mode 100644 index 000000000..6d2506923 --- /dev/null +++ b/doc/bugs/Allow_automatic_retry_git_annex_get/comment_4_899b66a20b8e29a23068d249a461c19f._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 4""" + date="2016-12-13T16:05:42Z" + content=""" +Could the original bug reporter please show what your ~/.ssh/config +contains? As far as I can tell, ssh's TCPKeepAlive option, which is +supposed to be enabled by default, unless you have disabled it, should +avoid such problems. + +It may also help to set ServerAliveInterval. + +Unfortunately, my attempt to make git-annex set ServerAliveInterval +when running ssh broke too many systems with old sshed, and I have had to +revert it. +"""]] diff --git a/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment new file mode 100644 index 000000000..a6a2397e7 --- /dev/null +++ b/doc/bugs/Assistant_drops_files_from_remote_repos_that_it_shouldn__39__t/comment_9_c46cdba62da4f5ccfdc42dfc33aec600._comment @@ -0,0 +1,34 @@ +[[!comment format=mdwn + username="boh" + avatar="http://cdn.libravatar.org/avatar/e7fa2d1c5d95e323fe48887f7f827b1f" + subject="comment 9" + date="2016-11-27T12:23:20Z" + content=""" +Seems as if the problem still exists in 6.20161118 (Debian). + +I have three repositories (among others), `jolla`, `sts-3xx`, and `here`. `jolla` and `here` are in group `manual`, `sts-3xx` is `backup`; `here` and `sts-3xx` have assistants running, `jolla` not. `jolla` and `sts-3xx` have slightly older versions of git-annex installed. + +Now, when I copy a file from `here` to `jolla` like this + + git annex copy real_programmers.png -t jolla + +the file is subsequently dropped by the assistant: + +``` +drop real_programmers.png (locking jolla...) [2016-11-27 13:00:02.667376556] chat: ssh [\"-S\",\".git/annex/ssh/jolla\",\"-o\",\"ControlMaster +=auto\",\"-o\",\"ControlPersist=yes\",\"-F\",\".git/annex/ssh.config\",\"-T\",\"jolla\",\"git-annex-shell 'lockcontent' '/~/Music/media/' '--debug' ' +SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png' --uuid 5298e3ce-1106-4d5e-b052-0aee4b27a344\"] +(locking sts-3xx...) [2016-11-27 13:00:03.252473676] chat: ssh [..., \"git-annex-shell 'lockcontent' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d 36380d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"] +(lockcontent failed) [2016-11-27 13:00:03.486158016] process done ExitFailure 1 +(checking sts-3xx...) [2016-11-27 13:00:03.487047149] call: ssh [..., \"git-annex-shell 'inannex' '/backups/exot/media/' '--debug' 'SHA256E-s84499--ff98a733cc0122858fb11433c720e2d038fec190a3d363 80d0e7e8dab468f883.png' --uuid 1fec6253-171d-4f86-885b-e233be2d65ec\"] +[2016-11-27 13:00:03.76435136] process done ExitSuccess +[2016-11-27 13:00:03.764705754] Dropping from here proof: Just (SafeDropProof (NumCopies 2) [RecentlyVerifiedCopy UUID \"1fec6253-171d-4 f86-885b-e233be2d65ec\",LockedCopy UUID \"5298e3ce-1106-4d5e-b052-0aee4b27a344\"] (Just (ContentRemovalLock (Key {keyName = \"ff98a733cc012 2858fb11433c720e2d038fec190a3d36380d0e7e8dab468f883.png\", keyBackendName = \"SHA256E\", keySize = Just 84499, keyMtime = Nothing, keyChun kSize = Nothing, keyChunkNum = Nothing})))) +[2016-11-27 13:00:04.24333081] process done ExitFailure 1 +ok +[2016-11-27 13:00:04.251232455] dropped real_programmers.png (from here) (copies now 4) : drop wanted after Upload UUID \"5298e3ce-1106- 4d5e-b052-0aee4b27a344\" real_programmers.png Just 84499 +``` + +However, I failed to reproduce the problem by replicating my setup with fresh repositories … + +Please let me know if you need more information, and *so* many thanks for git-annex! +"""]] diff --git a/doc/bugs/Build_with_aws_head_fails.mdwn b/doc/bugs/Build_with_aws_head_fails.mdwn new file mode 100644 index 000000000..a96dce0ad --- /dev/null +++ b/doc/bugs/Build_with_aws_head_fails.mdwn @@ -0,0 +1,49 @@ +### Please describe the problem. +https://github.com/aristidb/aws/issues/206 was recently resolved in https://github.com/aristidb/aws/pull/213. + +A newer version will be tagged imminently according to https://github.com/aristidb/aws/issues/206#issuecomment-260214736. + +With the http-conduit (<2.2.0) constraint removed from git-annex.cabal, and the aws dependency set to use aws head (currently c8806dc), the git-annex build fails. + +### What steps will reproduce the problem? + +Remove the http-conduit (<2.2.0) constraint and attempt to build git-annex with aws head. + +### What version of git-annex are you using? On what operating system? + +macOS 10.11, git-annex 6.20161118. + +### Please provide any additional information below. +Full build log: https://gist.github.com/ilovezfs/15bcd8f1086b3d825beff58140e04eec +[[!format sh """ +[ 90 of 542] Compiling Types.Crypto ( Types/Crypto.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Types/Crypto.o ) +[ 91 of 542] Compiling Utility.Metered ( Utility/Metered.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Metered.o ) +[ 92 of 542] Compiling Messages.JSON ( Messages/JSON.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Messages/JSON.o ) +[ 93 of 542] Compiling Utility.Url ( Utility/Url.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Url.o ) + +Utility/Url.hs:354:34: error: + • The constructor ‘StatusCodeException’ should have 2 arguments, but has been given 3 + • In the pattern: StatusCodeException s _ _ + In an equation for ‘matchStatusCodeException’: + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing + +Utility/Url.hs:354:34: error: + • Couldn't match expected type ‘HttpException’ + with actual type ‘HttpExceptionContent’ + • In the pattern: StatusCodeException s _ _ + In an equation for ‘matchStatusCodeException’: + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing +cabal: Leaving directory '.' +cabal: Error: some packages failed to install: +git-annex-6.20161118 failed during the building phase. The exception was: +ExitFailure 1 +"""]] + +### 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) +Yes :) + +> [[done]] via the nice patch! --[[Joey]] diff --git a/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment b/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment new file mode 100644 index 000000000..536c1569d --- /dev/null +++ b/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment @@ -0,0 +1,149 @@ +[[!comment format=mdwn + username="alpernebbi" + avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" + subject="Patch to fix aws head build issue" + date="2016-12-10T13:08:58Z" + content=""" +I think I fixed this. I'm attaching the output of `git format-patch origin/master`. + +In an Arch Linux chroot with their [PKGBUILD](https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/git-annex) (with a small modification to apply the patch), `haskell-http-client 0.5.3.3-1` and `http-conduit 2.2.3-5` both the build and the tests are successful. +It's also successful in a Debian Sid chroot, where `sudo apt build-dep git-annex` gives me `libghc-http-client-dev 0.4.31.1-3+b2`, `libghc-http-conduit-dev 2.1.11-3+b2`. + +### Patch + +[[!format patch \"\"\" +From 2ce09420aa8f3d916c6562abea4ed8911a186902 Mon Sep 17 00:00:00 2001 +From: Alper Nebi Yasak <alpernebiyasak@gmail.com> +Date: Sat, 10 Dec 2016 15:24:27 +0300 +Subject: [PATCH] Remove http-conduit (<2.2.0) constraint + +Since https://github.com/aristidb/aws/issues/206 is resolved, this +constraint is no longer necessary. However, http-conduit (>=2.2.0) +requires http-client (>=0.5.0) which introduces some breaking changes. +This commit also implements those changes depending on the version. +Fixes: https://git-annex.branchable.com/bugs/Build_with_aws_head_fails/ + +Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> +--- + Remote/S3.hs | 8 +++++++- + Remote/WebDAV.hs | 17 +++++++++++++++++ + Utility/Url.hs | 8 ++++++++ + git-annex.cabal | 3 +-- + 4 files changed, 33 insertions(+), 3 deletions(-) + +diff --git a/Remote/S3.hs b/Remote/S3.hs +index 4c1bd57..9563b5a 100644 +--- a/Remote/S3.hs ++++ b/Remote/S3.hs +@@ -49,6 +49,12 @@ import Annex.Content + import Annex.Url (withUrlOptions) + import Utility.Url (checkBoth, managerSettings, closeManager) + ++#if MIN_VERSION_http_client(0,5,0) ++import Network.HTTP.Client (responseTimeoutNone) ++#else ++responseTimeoutNone = Nothing ++#endif ++ + type BucketName = String + + remote :: RemoteType +@@ -430,7 +436,7 @@ withS3HandleMaybe c gc u a = do + where + s3cfg = s3Configuration c + httpcfg = managerSettings +- { managerResponseTimeout = Nothing } ++ { managerResponseTimeout = responseTimeoutNone } + + s3Configuration :: RemoteConfig -> S3.S3Configuration AWS.NormalQuery + s3Configuration c = cfg +diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs +index 19dbaa8..14947f1 100644 +--- a/Remote/WebDAV.hs ++++ b/Remote/WebDAV.hs +@@ -5,6 +5,7 @@ + - Licensed under the GNU GPL version 3 or higher. + -} + ++{-# LANGUAGE CPP #-} + {-# LANGUAGE ScopedTypeVariables #-} + + module Remote.WebDAV (remote, davCreds, configUrl) where +@@ -34,6 +35,10 @@ import Utility.Url (URLString, matchStatusCodeException) + import Annex.UUID + import Remote.WebDAV.DavLocation + ++#if MIN_VERSION_http_client(0,5,0) ++import Network.HTTP.Client (HttpExceptionContent(..), responseStatus) ++#endif ++ + remote :: RemoteType + remote = RemoteType { + typename = \"webdav\", +@@ -302,6 +307,17 @@ goDAV (DavHandle ctx user pass _) a = choke $ run $ prettifyExceptions $ do + {- Catch StatusCodeException and trim it to only the statusMessage part, + - eliminating a lot of noise, which can include the whole request that + - failed. The rethrown exception is no longer a StatusCodeException. -} ++#if MIN_VERSION_http_client(0,5,0) ++prettifyExceptions :: DAVT IO a -> DAVT IO a ++prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go ++ where ++ go (HttpExceptionRequest _ (StatusCodeException response message)) = error $ unwords ++ [ \"DAV failure:\" ++ , show (responseStatus response) ++ , show (message) ++ ] ++ go e = throwM e ++#else + prettifyExceptions :: DAVT IO a -> DAVT IO a + prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go + where +@@ -311,6 +327,7 @@ prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go + , show (statusMessage status) + ] + go e = throwM e ++#endif + + prepDAV :: DavUser -> DavPass -> DAVT IO () + prepDAV user pass = do +diff --git a/Utility/Url.hs b/Utility/Url.hs +index 9b68871..d0e1b37 100644 +--- a/Utility/Url.hs ++++ b/Utility/Url.hs +@@ -350,8 +350,16 @@ hUserAgent = \"User-Agent\" + - + - > catchJust (matchStatusCodeException (== notFound404)) + -} ++#if MIN_VERSION_http_client(0,5,0) ++matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException ++matchStatusCodeException want e@(HttpExceptionRequest _ (StatusCodeException r _)) ++ | want (responseStatus r) = Just e ++ | otherwise = Nothing ++matchStatusCodeException _ _ = Nothing ++#else + matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing + matchStatusCodeException _ _ = Nothing ++#endif +diff --git a/git-annex.cabal b/git-annex.cabal +index ec54a14..83d45a1 100644 +--- a/git-annex.cabal ++++ b/git-annex.cabal +@@ -357,8 +357,7 @@ Executable git-annex + resourcet, + http-client, + http-types, +- -- Old version needed due to https://github.com/aristidb/aws/issues/206 +- http-conduit (<2.2.0), ++ http-conduit, + time, + old-locale, + esqueleto, +-- +2.7.4 + +\"\"\"]] + +"""]] diff --git a/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn new file mode 100644 index 000000000..8f1995697 --- /dev/null +++ b/doc/bugs/Corrupted_git___40__but_not_annex__41___controlled_files.mdwn @@ -0,0 +1,102 @@ +### Please describe the problem. + +I have files that match annex.largefiles and therefore should be added to git but not to annex, they seem to be getting corrupted after cloning the repo. + +### What steps will reproduce the problem? + +I couldn't immediately find the exact steps to reproduce the issue but I have multiple git repositories showing this. + +### What version of git-annex are you using? On what operating system? + +The problem has occurred a while ago but I have just noticed it. This is on macOS if it helps. I also tend to use the latest released version of git-annex (installed via Homebrew) + +### 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 + +$ cd Documents +$ cat .gitattributes +* annex.largefiles=((not(mimetype=text/*))or(largerthan=100kb)) + +*.png binary +*.jpg binary +*.jpeg binary +*.gif binary +*.ico binary + +*.mp3 binary +*.fla binary + +*.mov binary +*.mp4 binary +*.flv binary +*.swf binary +*.avi binary +*.mkv binary +*.mpg binary +*.mpeg binary + +*.gz binary +*.zip binary +*.7z binary +*.rar binary +*.bz2 binary + +*.ttf binary + +*.pdf binary + +$ ls -la Docs/2016-XXX/XXX/ +total 696 +drwx------@ 4 denis staff 136 Jul 11 15:05 ./ +drwxr-xr-x@ 9 denis staff 306 Dec 12 19:42 ../ +-rwxr-xr-x@ 1 denis staff 265898 Jul 11 13:03 XXX.pdf* +-rwxr-xr-x@ 1 denis staff 89586 Jul 11 13:03 Summary.pdf* +$ file --mime-type Docs/2016-XXX/XXX/XXX.pdf +Docs/2016-XXX/XXX/XXX.pdf: application/pdf +$ git show 60a76858a57a73967131b929af45a99703f67335 +commit 60a76858a57a73967131b929af45a99703f67335 +Author: Denis Dzyubenko <denis@ddenis.info> +Date: Mon Jul 11 15:05:37 2016 +0200 + + XXX + +diff --git a/Docs/2016-XXX/XXX/XXX.pdf b/Docs/2016-XXX/XXX/XXX.pdf +new file mode 100755 +index 00000000..112f68d0 +Binary files /dev/null and b/Docs/2016-XXX/XXX/XXX.pdf differ +diff --git a/Docs/2016-XXX/XXX/Summary.pdf b/Docs/2016-XXX/XXX/Summary.pdf +new file mode 100755 +index 00000000..3828383e +Binary files /dev/null and b/Docs/2016-XXX/XXX/Summary.pdf differ +diff --git a/Docs/2016-XXX/XXX.pdf b/Docs/2016-XXX/XXX.pdf +deleted file mode 120000 +index 6d347a22..00000000 +--- a/Docs/2016-XXX/XXX.pdf ++++ /dev/null +@@ -1 +0,0 @@ +-../../.git/annex/objects/zJ/X1/SHA256E-s190749--ee0c8329c88f9c1656cc75cf37d4df64060a022e73d199164c5e5222ba1739d1.pdf/SHA256E-s190749--ee0c8329c88f9c1656cc +\ No newline at end of file + + + +$ git clone Documents Documents.tmp +Cloning into 'Documents.tmp'... +done. +$ cd ./Documents.tmp/ +$ ls -la Docs/2016-XXX/XXX/ +total 184 +drwxr-xr-x 4 denis staff 136 Dec 19 00:09 ./ +drwxr-xr-x 8 denis staff 272 Dec 19 00:09 ../ +-rwxr-xr-x 1 denis staff 101 Dec 19 00:09 XXX.pdf* +-rwxr-xr-x 1 denis staff 89586 Dec 19 00:09 Summary.pdf* +$ cat Docs/2016-XXX/XXX/XXX.pdf +/annex/objects/SHA256E-s265898--9c750c01dce9689ac3880224d2e95da6287b0cc89759c0c882e7a9a0fe48d664.pdf + +# End of transcript or log. +"""]] + +### 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) + diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn new file mode 100644 index 000000000..a3b85bdf2 --- /dev/null +++ b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed.mdwn @@ -0,0 +1,30 @@ +### Please describe the problem. +Issue uploading to S3 remote (Dreamhost) + +### What steps will reproduce the problem? +git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud +on my repo + +### What version of git-annex are you using? On what operating system? +6.20161031-g0a58e94 +OS-X 10.11.6 + +### Please provide any additional information below. +I am using a different WIFI I haven't used before. Maybe it is blocking something… + +[[!format sh """ +git-annex copy massart/f16_Web1/screencaptures/IMG_5159.MOV --to=cloud +copy massart/f16_Web1/screencaptures/IMG_5159.MOV (checking cloud...) (to cloud...) +17% 0.0 B/s 0sgpg: error running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent': probably not installed +gpg: DBG: running `/Users/joey/homebrew/opt/gpg-agent/bin/gpg-agent' for testing failed: Configuration error +gpg: can't connect to the agent: IPC connect call failed +gpg: problem with the agent: No agent running +35% 1021.8KB/s 30s + user error (gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","26","--symmetric","--force-mdc","--no-textmode"] exited 2) +failed +git-annex: copy: 1 failed +"""]] + +### 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) +Yes. + diff --git a/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment new file mode 100644 index 000000000..02b62f46e --- /dev/null +++ b/doc/bugs/DBG__58___running___96____47__Users__47__joey__47__homebrew__47__opt__47__gpg-agent__47__bin__47__gpg-agent__39___for_testing_failed/comment_1_39718e8a35e42421a8aaf3316ae1d76a._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="andrew" + avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435" + subject="RESOLVED" + date="2016-11-17T14:59:15Z" + content=""" +Ooops. I am on OS-X. I use brew for my gnupg installation. It appears I had removed gpg from the path when installing something. I just needed to run to fix: + + brew link gnupg2 + +Thanks, + +Andrew +"""]] diff --git a/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn new file mode 100644 index 000000000..c9037b575 --- /dev/null +++ b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis.mdwn @@ -0,0 +1,53 @@ +### Please describe the problem. + +I'm seeing some inconsistent results between runs of `git annex fsck` and `git annex whereis` that I'm not able to explain. When I run `git annex fsck`, it reports a few keys that only have 1 copy, and advises me to make more copies. If I run `git annex whereis --key <key>`, git annex confirms that it only knows about 1 copy of this key. If I then use `git log --stat -S'<key>'` to find the actual file that it refers to, and run `git annex whereis <file>`, git annex report 9 copies of this file. Checking on remotes shows that these files do exist on the remote, so why does `git annex fsck` and `git annex whereis` mis-report the number of copies when querying for the key - but not for the actual filename? Additionally, `git annex find --lackingcopies 1` doesn't return any results, but should if there are actually files with not enough copies? + + +### What steps will reproduce the problem? + + +### What version of git-annex are you using? On what operating system? + +5.20151208-1build1 on Ubuntu Xenial, one remote running 5.20141024~bpo70+1 on Debian Wheezy + +### 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 + +[william@hactar ~/Pictures/Photo Library]$ git annex whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +git-annex: SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 not found +git-annex: whereis: 1 failed +[william@hactar ~/Pictures/Photo Library]$ git annex whereis --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +whereis SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 (1 copy) + 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here] +ok +[william@hactar ~/Pictures/Photo Library]$ git annex fsck --key SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 +fsck SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 + Only 1 of 3 trustworthy copies exist of SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9 + Back it up with git-annex copy. +failed +(recording state in git...) +git-annex: fsck: 1 failed +[william@hactar ~/Pictures/Photo Library]$ git log --stat -S'SHA256E-s1071765--dbaa7f32ee44c28d6a1f0c8095e8dfd8b4ec433b144085d5097425303a510ea9' +[william@hactar ~/Pictures/Photo Library]$ git annex whereis 2009/05/05/P1040890.JPG +whereis 2009/05/05/P1040890.JPG (9 copies) + 0e825a69-1927-4f62-b731-6f3e98bba998 -- william@marvin:/media/backup/annex/photos [marvin] + 1b728ab5-1e32-45a6-bc11-2a4bfdc9d6ab -- backup1 + 5c0caa42-b489-467b-a612-9590fa9d5a94 -- backup2 + 7691934f-2542-4103-9122-2db4e6cfc887 -- hactar [here] + 894b2216-72e0-40e1-8765-1386e1e9e4b4 -- backup3 + 96f19fa8-d385-4e8b-b000-61ee15993a70 -- backup3 + a862b121-d794-4af4-bb56-21adfe8962f2 -- S3 + b083f8ae-42fb-41f0-a2a3-4e7c9f93aadb -- [guide] + bf021ce9-465b-4419-86e7-bddfd208fca4 -- git@newzaphod:~/repositories/annex/photos.git [zaphod] +ok + + +# End of transcript or log. +"""]] + +### 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 trust Git Annex to keep hundreds of GB of data safe, and it has never failed me - despite my best efforts diff --git a/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis/comment_1_bd56607f228f3480f1355e3bdb755410._comment b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis/comment_1_bd56607f228f3480f1355e3bdb755410._comment new file mode 100644 index 000000000..d65f39fd0 --- /dev/null +++ b/doc/bugs/Inconsistent_results_between_git-annex-fsck_and_git-annex-whereis/comment_1_bd56607f228f3480f1355e3bdb755410._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-13T16:42:08Z" + content=""" +The obvious reason for this would be if the file no longer points to that +same key. Perhaps the file got modified and the key is the old version of +the file. + +That would explain everything you showed, so currently I don't see any +bug.. +"""]] diff --git a/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn new file mode 100644 index 000000000..73c7ae864 --- /dev/null +++ b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8.mdwn @@ -0,0 +1,88 @@ +### Please describe the problem. +I had also commented this on [[another bug|bugs/git-annex_fromkey_barfs_on_utf-8_input]], but the original issue there is fixed now. +I tested `fromkey`, `calckey --batch`, `lookupkey --batch` (in standalone) after your fix, they work nicely. + +However, `git-annex metadata --batch --json` using the [[linux standalone|install/Linux_standalone]] (autobuild) still fails when it encounters UTF-8 characters (e.g. ü, ç, ä). +Also, `git-annex metadata --json` gives `"file":"��.txt"` for `ü.txt`. + +This happens only in the standalone builds. + +### What steps will reproduce the problem? + +[[!format sh """ +$ .../git-annex.linux/runshell +$ touch u.txt ü.txt +$ git-annex add . + +$ git-annex metadata --batch --json +{"file":"ü.txt"} +git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream + +$ git-annex metadata --batch --json +{"file":"u.txt","fields":{"ç":["b"]}} +git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream + +$ git-annex metadata --batch --json +{"file":"u.txt","fields":{"b":["ä"]}} +git-annex: Batch input parse failure: Error in $: Failed reading: Cannot decode byte '\xb3': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream + +$ git-annex metadata --json +{"command":"metadata","note":"","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"u.txt","fields":{}} +{"command":"metadata","note":"","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"��.txt","fields":{}} +# success, but the second line should have "file":"ü.txt" +"""]] + +It's the same even if I call `.../git-annex.linux/git-annex` directly (without `runshell`) + +### What version of git-annex are you using? On what operating system? +Using the Linux standalone: [git-annex-standalone-amd64.tar.gz](https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz) on Xubuntu 16.04 + +[[!format sh """ +$ git-annex version +git-annex version: 6.20161213-g55a34b493 +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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external +local repository version: 5 +supported repository versions: 3 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +operating system: linux x86_64 +"""]] + +### Please provide any additional information below. + +None of the characters I used have `\xb3` in it, but all the errors happen due to it: +[[!format sh """ +$ .../git-annex.linux/runshell +$ echo -n ü | xxd +00000000: c3bc .. +$ echo -n ç | xxd +00000000: c3a7 .. +$ echo -n ä | xxd +00000000: c3a4 .. +"""]] + +In `runshell`, `ls` can't show UTF-8, but `git-annex status` can: +[[!format sh """ +$ .../git-annex.linux/runshell +$ ls +u.txt ??.txt +$ git-annex status +A u.txt +A ü.txt +"""]] + +`man` complains about locale in `runshell` as well: +[[!format sh """ +$ .../git-annex.linux/runshell +$ man +man: can\'t set the locale; make sure $LC_* and $LANG are correct +What manual page do you want? +# I escaped that \', formatting was messy otherwise +$ set | grep LANG +GDM_LANG='en_GB' +LANG='en_GB.UTF-8' +LANGUAGE='en_GB:en' +$ set | grep LC +# nothing +"""]] diff --git a/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment new file mode 100644 index 000000000..4a15b1987 --- /dev/null +++ b/doc/bugs/Linux_standalone__39__s_metadata_--batch_can__39__t_parse_UTF-8/comment_1_1765400777911cc61eb591b76c84ae89._comment @@ -0,0 +1,45 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-19T20:37:56Z" + content=""" +runshell was recently changed to bypass using the system locales, it +includes its own locale data and attempts to generate a locale definition +file for the locale. The code that did that was failing to notice that +en_GB.UTF-8 was a UTF-8 locale (en_GB.utf8 would work though), which +explains why the locale is not set inside runshell +(git-annex.linux/git-annex is a script that uses runshell). I've corrected +that problem, and verified it fixes the problem you reported. + +---- + +However.. The same thing happens when using LANG=C with git-annex +installed by any method and --json --batch. So the deeper problem is that +it's forcing the batch input to be decoded as utf8 via the current locale. +This happens in Command/MetaData.hs parseJSONInput which uses +`BU.fromString`. + +I tried swapping in `encodeBS` for `BU.fromString`. That prevented the +decoding error, but made git-annex complain that the file was not annexed, +due to a Mojibake problem: + +With `encodeBS`, the input `{"file":"ü.txt"}` is encoded as +`"{\"file\":\"\195\188.txt\"}"`. Aeson parses that input to this: + + JSONActionItem {itemCommand = Nothing, itemKey = Nothing, itemFile = Just "\252.txt", itemAdded = Nothing} + +Note that the first two bytes have been +parsed by Aeson as unicode (since JSON is unicode encoded), +yielding character 252 (ü). + +In a unicode locale, this works ok, because the encoding layer is able to +convert that unicode character back to two bytes 195 188 +and finds the file on disk. But in a non-unicode locale, it doesn't know +what to do with the unicode character, and in fact it gets discarded +and so it looks for a file named ".txt". + +So, to make --batch --json input work in non-unicode locales, it would +need, after parsing the json, to re-encode filenames (and perhaps other +data), from utf8 to the filesystem encoding. I have not yet worked out how +to do that. +"""]] diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn new file mode 100644 index 000000000..26790bea3 --- /dev/null +++ b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn @@ -0,0 +1,85 @@ +### Please describe the problem. + +While running `git-annex metadata --batch --json`, repeatedly assigning a field to the same value in the same run (with different values in between the assignments of the same value) causes a value to get stuck. + +### What steps will reproduce the problem? + + $ touch test.txt + $ git annex add + $ git-annex metadata --batch --json + {"file":"test.txt","fields":{"f":["a"]}} + # prints { ... "f":["a"] ... } + {"file":"test.txt","fields":{"f":["b"]}} + # prints { ... "f":["b"] ... } + {"file":"test.txt","fields":{"f":["c"]}} + # prints { ... "f":["c"] ... } + {"file":"test.txt","fields":{"f":["a"]}} + # prints { ... "f":["a", "c"] ... } + {"file":"test.txt","fields":{"f":["b"]}} + # prints { ... "f":["c"] ... } + +### What version of git-annex are you using? On what operating system? + + git-annex version: 6.20161122+gitg9f179ae-1~ndall+1 + 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 + local repository version: 5 + supported repository versions: 3 5 6 + upgrade supported from repository versions: 0 1 2 3 4 5 + operating system: linux x86_64 + +I'm using Xubuntu 16.04, with the `git-annex-standalone` package from NeuroDebian repository. + +### Please provide any additional information below. + +If you keep reassigning the same values, things get very weird. Full inputs/outputs from a sample run: + + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=a\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields": {"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"f=b\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b"]}} + {"file":"test.txt","fields":{"f":["c"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":[]}} + {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}} + {"file":"test.txt","fields":{"f":["c"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":["c"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + {"file":"test.txt","fields":{"f":["b"]}} + {"command":"metadata","note":"f=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=a\nf=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","b","c"]}} + {"file":"test.txt","fields":{"f":["d"]}} + {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} + {"file":"test.txt","fields":{"f":["a"]}} + {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} + {"file":"test.txt","fields":{"f":[]}} + {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} + +Restarting the process solves the issue. + +### 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 love the metadata functionality so much that I wrote [[tips/a_gui_for_metadata_operations]] and discovered this bug. +Metadata driven views are awesome (but I don't like the entire folder hierarchy being appended to the filename). +I haven't used the other commands much since I have not yet organized most of my stuff (and their naively copy-pasted backups), but I am glad I discovered git-annex before I began organizing. + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment new file mode 100644 index 000000000..4f82db153 --- /dev/null +++ b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-13T14:40:02Z" + content=""" +I thought this would involve the journal, but it seems not; same +behavior occurs if the journal is committed after each metadata change. + +Looking at the new metadata value in the case where a and c both get set, +it is: + + MetaData (fromList [(MetaField "f",fromList [MetaValue (CurrentlySet True) "a",MetaValue (CurrentlySet False) "c"])]) + +That is supposed to unset c, with the CurrentlySet False, but instead c +remains set somehow. + +Aha, the use of `addMetaData'` causes the bug. That reuses the same +timestamp, and indeed the same timestamp is used for all the batch +changes. With the same timestamp for the log line that sets c as the line +that removes it, it's indeterminite which line will be acted on first, and +so the removal can be processed before the addition, leaving c "stuck". + +Fixing.. +"""]] diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment new file mode 100644 index 000000000..820e6b040 --- /dev/null +++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_2_c227071f23a96ed9928f128e7f77e503._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91" + nickname="justin.lebar" + avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e" + subject="comment 2" + date="2016-11-20T03:47:23Z" + content=""" +Thanks for your reply, Joey. Sorry for the delay getting back to this -- I didn't realize I hadn't enabled notifications on the thread. + +The GCS docs suggest that 400 errors should be accompanied by an explanation in the reply body. + +> Error responses usually include a JSON document in the response body, which contains information about the error. + +https://cloud.google.com/storage/docs/json_api/v1/status-codes + +Do you think we're not getting an http response body here, or that it's not being printed out? +"""]] diff --git a/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment new file mode 100644 index 000000000..67b215bc7 --- /dev/null +++ b/doc/bugs/Nearline_bucket_stopped_working___40__can__39__t_even_HEAD_files__41__/comment_3_5ac676877feaa7cdb9e05d6b71b1a4c3._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91" + nickname="justin.lebar" + avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e" + subject="comment 3" + date="2016-12-04T04:30:38Z" + content=""" +For a while things were working, but now it's not working again, same problem as before. + +Do you think maybe it's a timestamp bug in the signature or something? That could explain this \"mysteriously works then stops working\" behavior. +"""]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn new file mode 100644 index 000000000..096562199 --- /dev/null +++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn @@ -0,0 +1,57 @@ +### Please describe the problem. + +If a filename has a single space (and only one space), `git annex add` will fail out with the following message: + + add one two git-annex: unknown response from git cat-file ("HEAD:./one two missing",Ref "HEAD:./one two") + CallStack (from HasCallStack): + error, called at ./Git/CatFile.hs:102:28 in main:Git.CatFile + +### What steps will reproduce the problem? + +Run the following: + + git init . + git annex init + touch "one two" + # this will cause error + git annex add "one two" + touch "one two three" + # this is fine + git annex add "one two three" + +### What version of git-annex are you using? On what operating system? + +Output of `git annex version` + + git-annex version: 6.20161027 + 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 + local repository version: 5 + supported repository versions: 3 5 6 + upgrade supported from repository versions: 0 1 2 3 4 5 + operating system: linux x86_64 + +Operating System: Linux (NixOS 16.09.909.238c7e0 (Flounder)) + +### Please provide any additional information below. + +Maybe related to [https://git-annex.branchable.com/forum/unknown_response_from_git_cat-file/](https://git-annex.branchable.com/forum/unknown_response_from_git_cat-file/) or [https://git-annex.branchable.com/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/](https://git-annex.branchable.com/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/)? + +EDIT: Somewhat surprisingly, if I build from source using `cabal`, everything works fine. + + .cabal-sandbox/bin/git-annex version + git-annex version: 6.20161113-g1e88c12 + build flags: Assistant Webapp Pairing Testsuite WebDAV Inotify 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 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external + +Not sure whether this means that this bug is actually fixed or whether it's an artifact of how things are built in Nix. + +### 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) + +Just starting out with it as a way of archiving some of my media seems to work great apart from this. Thanks a bunch! + +> This bug was already fixed in git-annex 6.20161031. I told the Debian +> maintainer about the bug fix at the time; package has not been updated +> yet. [[done]] on git-annex side. --[[Joey]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment new file mode 100644 index 000000000..5f8b120e2 --- /dev/null +++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="gfa@1e86118cd41fbfea50004af221471ad97b55af18" + nickname="gfa" + avatar="http://cdn.libravatar.org/avatar/4678da4da55c67fa668e31ea0a76b201" + subject="same on Debian" + date="2016-11-14T09:13:19Z" + content=""" +I face the same issue on Debian testing + +git-annex 6.20161012-1 +git 1:2.10.2-1 +"""]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment new file mode 100644 index 000000000..bf41d40a5 --- /dev/null +++ b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://launchpad.net/~stephane-gourichon-lpad" + nickname="stephane-gourichon-lpad" + avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089" + subject="Known bug, fixed." + date="2016-11-23T18:04:27Z" + content=""" +This is a known bug introduced in 6.20161012 and fixed in 6.20161031. + +Solution is: just update your copy of git-annex. At this time most recent is 6.20161119 . + +For more details, see changelog at https://github.com/joeyh/git-annex/blob/master/CHANGELOG#L53 + + + +"""]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn index 0c3fc16a1..17fe3ac25 100644 --- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn +++ b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn @@ -30,4 +30,5 @@ operating system: darwin x86_64 ### 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) - +> [[done]], my fix worked! Don't know entirely why it was needed.. +> --[[Joey]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment new file mode 100644 index 000000000..cb6e9b4d2 --- /dev/null +++ b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="christopher@5845ecd3cef9edadd4dc084df00e1fa60ce311eb" + nickname="christopher" + avatar="http://cdn.libravatar.org/avatar/4b722efb21f38d9944730c93727bc602" + subject="comment 3" + date="2016-11-15T12:15:37Z" + content=""" +Hi Joey, + +I installed git-annex using the homebrew recipe from https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-annex.rb, OS X 10.11.6 (15G31) + +These are the dependencies reported by homebrew: + +Build: ghc ✔, cabal-install ✔, pkg-config ✔ +Required: gsasl ✔, libidn ✔, libmagic ✔, gnutls ✔, quvi ✔ + +I've re-installed using \"brew install git-annex --HEAD\" to pull in your latest commit and I can confirm that everything works as expected and the /static/ resources load correctly. + +Thanks, +Chris +"""]] diff --git a/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken.mdwn b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken.mdwn new file mode 100644 index 000000000..a8df72354 --- /dev/null +++ b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken.mdwn @@ -0,0 +1,40 @@ +### Please describe the problem. + +``` +> git annex get Narnia/ +get Narnia/Course of a Generation/01 Sail Around the World.mp3 (from Seagate...) +SHA256E-s8395599--2fea961006a279f0765c45755b35a06f0a4fc6bfbab6118182ebc693d7b47a91.mp3 + 8,395,599 100% 29.65MB/s 0:00:00 (xfr#1, to-chk=0/1) +(checksum...) ^C⏎ +``` + +``` +> mpv ~/Music/sorted/Narnia/Course\ of\ a\ Generation/ +Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/ +[file] This is a directory - adding to playlist. + +Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/01 Sail Around the World.mp3 +Failed to recognize file format. + +Playing: /home/philip/Music/sorted/Narnia/Course of a Generation/02 When the Stars Are Falling.mp3 +``` + +``` +> git annex version +git-annex version: 6.20161012 +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 +local repository version: 6 +supported repository versions: 3 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +operating system: linux x86_64 +``` + +Any consecutive `git annex get` commands don’t notice that the file is not completely transferred and leave it in a broken state. +`git annex get --failed` does not correct the problem. + + +### 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) + +Yes, it (kind of) works for keeping my music library in sync. diff --git a/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment new file mode 100644 index 000000000..4f90ddfa6 --- /dev/null +++ b/doc/bugs/When_stopping___96__git_annex_get__96___files_left_broken/comment_1_9392346203c561b88f30fa2ce7540b76._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-11-16T18:36:34Z" + content=""" +Thing is, git-annex get does not update the file in place. Only once the +entire file is downloaded, and its content is verified correct is it moved +into a place where you can access it. + +So, it seems much more likely to me that the content of the file, as +originally added to git-annex, was bad, and the it had just finished +verifying the content and moving it into place when you interruped the +command. + +Please check with `git annex fsck` on the file and see if it determines +it has the content git-annex expects it to have. + +However, I notice you're using a v6 repository. Is the file an unlocked +file? It's possible that in that specific case there could be a bug. +I've interrupted `git annex get` on a nearly daily basis for years, but +v6 is still experimental and not as well tested. +"""]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed.mdwn b/doc/bugs/YouTube_-_error_in_importfeed.mdwn new file mode 100644 index 000000000..d300c621f --- /dev/null +++ b/doc/bugs/YouTube_-_error_in_importfeed.mdwn @@ -0,0 +1,74 @@ +### Please describe the problem. +When adding a YouTube channel via importfeed I get the error: + +``` + warning: bad feed content; no enclosures to download +``` + +### What steps will reproduce the problem? +1. `cd $(mktemp -d)` +2. `git init && git annex init` +3. `git annex importfeed https://www.youtube.com/feeds/videos.xml\?playlist_id\=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet` +4. Get sad. :-( + +(URL [https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet](https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet) looks like a feed to Firefox) + + +### What version of git-annex are you using? On what operating system? +OSX (MacOS?) - installed via homebrew + + git-annex version: 6.20161210 + build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external + +Debian Jessie - installed via apt-get (ASIDE: why is the apt-get version sooooo old?) + + git-annex version: 5.20141125 + build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify 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 ddar hook external + + +### Additional information + +Running with `--debug` (see below) seems to indicate that the feed downloads correctly, but it is the parsing that is failing. I don't know what command is being run to parse the feed though. + + +``` shell +git annex importfeed --debug https://www.youtube.com/feeds/videos.xml\?playlist_id\=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet +``` +results in: + +``` shell +(checking known urls...) [2016-12-19 12:39:36.387714] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] +[2016-12-19 12:39:36.392367] process done ExitSuccess +[2016-12-19 12:39:36.392496] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] +[2016-12-19 12:39:36.396484] process done ExitSuccess +[2016-12-19 12:39:36.406716] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."] +[2016-12-19 12:39:36.412674] process done ExitSuccess +importfeed https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet +[2016-12-19 12:39:36.413555] call: wget ["--clobber","-c","-O","/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249","https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet","--user-agent","git-annex/6.20161210"] +--2016-12-19 12:39:36-- https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet +Resolving www.youtube.com... 216.58.199.78, 2404:6800:4006:806::200e +Connecting to www.youtube.com|216.58.199.78|:443... connected. +HTTP request sent, awaiting response... 200 OK +Length: unspecified [text/xml] +Saving to: ‘/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249’ + +/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/f [ <=> ] 23.81K --.-KB/s in 0.02s + +2016-12-19 12:39:37 (1.22 MB/s) - ‘/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249’ saved [24386] + +[2016-12-19 12:39:37.595869] process done ExitSuccess + + warning: bad feed content; no enclosures to download +ok +``` + +### 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) + +Yes, for years. I donated to fund the dev and proudly display my git-annex stickers! + +> This is now fixed in feed's git repository, and will be in the next +> release of feed after the current 0.3.11.1 release. [[done]] --[[Joey]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment b/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment new file mode 100644 index 000000000..afdff4942 --- /dev/null +++ b/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-19T19:55:23Z" + content=""" +It's somewhat misleading that it complains there are no enclosures in the +feed. While importfeed mostly downloads only enclosures in podcast feeds, +it also checks link tags, which this feed contains, to see if quvi supports +downloading content from them. Quvi does support the links in this feed, +so it should work despite there being no enclosures. + +I've reproduced it not working, and it seems that the problem is this is +not quite a valid Atom feed, and the feed parsing library is failing to +parse it. Perhaps that can be improved; I filed a bug here +<https://github.com/bergmark/feed/issues/18> +"""]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment b/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment new file mode 100644 index 000000000..edf4c855c --- /dev/null +++ b/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="m8r-achx62@7323980ed426b7f78c85dfefe7358672bce44e98" + nickname="m8r-achx62" + avatar="http://cdn.libravatar.org/avatar/adaf4c4277529e10e32c467fa4ed4b9a" + subject="comment 2" + date="2016-12-19T22:33:13Z" + content=""" +Thanks for following this up Joey! +"""]] diff --git a/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn b/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn new file mode 100644 index 000000000..d4e3ad471 --- /dev/null +++ b/doc/bugs/__34__commitBuffer__58___invalid_argument___40__invalid_character__41____34___during___34__git_annex_sync__34__.mdwn @@ -0,0 +1,52 @@ +### Please describe the problem. + +In my unlocked adjusted branch, I get a lot of errors during "git annex sync". It appears to work fine otherwise (the files actually get synced). Below is what I see on the terminal. The repository is otherwise clean (no local or remote changes). +This has started to happen around a month ago, though I cannot pinpoint the exact version. This is in the same repo you used to debug the disappearing files in direct mode recently (thanks a lot btw!). + +### What version of git-annex are you using? On what operating system? + +[[!format sh """ +$ git annex version +git-annex version: 6.20161110-gd48f4ca +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 +$ lsb_release -a +No LSB modules are available. +Distributor ID: Debian +Description: Debian GNU/Linux 8.6 (jessie) +Release: 8.6 +Codename: jessie +"""]] + +### Please provide any additional information below. + +[[!format sh """ +$ git annex sync --content +commit +On branch adjusted/master(unlocked) +nothing to commit, working tree clean +ok +pull origin +remote: Counting objects: 113, done. +remote: Compressing objects: 100% (113/113), done. +remote: Total 113 (delta 112), reused 0 (delta 0) +Receiving objects: 100% (113/113), 7.16 KiB | 0 bytes/s, done. +Resolving deltas: 100% (112/112), completed with 112 local objects. +From /srv/annex/bilder + 97a4806..78cb4ef git-annex -> origin/git-annex +ok +(merging origin/git-annex into git-annex...) + +git-annex: fd:25: commitBuffer: invalid argument (invalid character) +failed + +git-annex: fd:25: commitBuffer: invalid argument (invalid character) +failed + +[...] + +git-annex: fd:25: commitBuffer: invalid argument (invalid character) +failed +git-annex: sync: 2653 failed +"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment new file mode 100644 index 000000000..a5d988fae --- /dev/null +++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_1_e308245bf81a536db6f9a2b743d912bf._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-11-16T18:49:09Z" + content=""" +I'm not able to reproduce the problem with your test case and git-annex +version 6.20161012. + +Can you still reproduce it after upgrading? +"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment new file mode 100644 index 000000000..1046fb066 --- /dev/null +++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_2_b3998823aca4266089dcbcf325d8f8c1._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="t.z.mates" + avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" + subject="comment 2" + date="2016-11-19T04:42:25Z" + content=""" +Thanks for looking into it; I just checked again, and even on the newest version (6.20161118 binary), I'm still experiencing the behavior. However, I checked on an older OpenSuse box I have, and there it works (6.20161031 from OpenSuse repo). + +Since my two machines experiencing the problem are both running arch, it seems it's somehow related to that distro. I've checked both installing via the binary (from kitenet) and from the arch community repo, but both produce the same behavior. Further, the OpenSuse install has the same build flags as the binaries, so that doesn't seem to be it. Are there any other diagnostics I can run? + +This particular problem isn't very troublesome (it doesn't seem to have any material impact aside from error messages); however, I also occasionally experience a more serious bug. Namely, when certain (seemingly random) files are added to the repo locked, their content disappears and the symlink is broken (this is the other problem I alluded to in the description). I suspect that problem is related to this one though, since it also only affects my arch machines. I haven't yet submitted a report for that bug yet, though, since I can't reliably replicate it. +"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment new file mode 100644 index 000000000..918bb4bac --- /dev/null +++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_3_d74835534f52c7f123b14e5d74194733._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-12-13T16:54:11Z" + content=""" +Perhaps it's caused by a particular/old version of git? +"""]] diff --git a/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment new file mode 100644 index 000000000..af0b2030b --- /dev/null +++ b/doc/bugs/add_fails_with_v6_repo_when_four_levels_deep/comment_4_f9d6dffb2617715c58216f54016de3a4._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="t.z.mates" + avatar="http://cdn.libravatar.org/avatar/90f15fad216078fd08d62cc676487925" + subject="comment 4" + date="2016-12-20T23:08:44Z" + content=""" +Hmm, I don't think an old version of git is the cause. I'm currently running the most recent build of git (2.11.0), but have used a number of versions over the past year. + +I'm not sure if this is relevant, but this other bug reports similar behavior: [sync --content, fatal is outside repository errors](https://git-annex.branchable.com/forum/sync_--content__44___fatal_is_outside_repository_errors/). Specifically, it notes that there is an odd use of relative paths: +> The relative path ../Users is curious + +My error also appends an extra period. In particular, the path should be \"./1/2/3/4/foo\" but prints \"../1/2/3/4/foo\". +"""]] diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn new file mode 100644 index 000000000..a5cdfd6d6 --- /dev/null +++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn @@ -0,0 +1,41 @@ +### Please describe the problem. + +When addurl'ing a big file with .gitattributes configured to add only some files directly into git (and 'git annex add' operating correctly), addurl adds large files straight into git. + +### What version of git-annex are you using? On what operating system? + +git-annex version: 6.20161018+gitgf3c366a-1~ndall+1 + + +### Please provide any additional information below. + +[[!format sh """ +$> cat .gitattributes +* annex.backend=MD5E +* annex.largefiles=(largerthan=100kb) +*.json annex.largefiles=nothing +*.txt annex.largefiles=nothing +*.tsv annex.largefiles=nothing +*.nii.gz annex.largefiles=(largerthan=0kb) +*.tgz annex.largefiles=(largerthan=0kb) +*.tar.gz annex.largefiles=(largerthan=0kb) +*.gz annex.largefiles=(largerthan=0kb) + +$> git annex addurl http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz\?versionId\=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. +addurl fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. (downloading http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz?versionId=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. ...) +/mnt/btrfs/datasets/datalad/crawl-misc/indi/ 100%[==============================================================================================>] 195.44M 21.2MB/s in 12s +(non-large file; adding content to git repository) ok +(recording state in git...) +cached/staged changes: + \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes + +$> ls -l fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. +-rw------- 1 yoh datalad 204937338 Oct 25 17:30 fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. +cached/staged changes: + \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes + +"""]] + +[[!meta author=yoh]] + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment new file mode 100644 index 000000000..e03e574f3 --- /dev/null +++ b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-11-21T15:12:54Z" + content=""" +It's sufficient to have "* annex.largefiles=(largerthan=100kb)" +in .gitattributes. + +Even "* annex.largefiles=(largerthan=0kb)" will reproduce it. + +Ok, I see why.. It's running the largefile matcher on the destination file +before it renames the temp file to it! + +Seems to have been broken this way ever since addurl got largefiles +support. Testing didn't catch it because it only affects largefiles +expressions that need to examine the file. + +Fixed in git. Audited other checkFileMatcher calls for this problem; +the rest are ok. +"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading.mdwn b/doc/bugs/addurl_pathdepth_description_misleading.mdwn index 531e43cbf..7bb9d582a 100644 --- a/doc/bugs/addurl_pathdepth_description_misleading.mdwn +++ b/doc/bugs/addurl_pathdepth_description_misleading.mdwn @@ -11,3 +11,7 @@ This isn't how it behaves. It would be more accurate as (emphasis on changes): > For example, adding the url http://www.example.com/dir/subdir/bigfile with --pathdepth=1 will use "**dir_subdir_bigfile**", while --pathdepth=3 will use "bigfile". For what I am doing (adding a directory tree with addurl and file:// URLs), I'd actually like the behaviour described (to recreate the tree), but I'm not sure which one was the *intended* behaviour.. + +> [[done]]; bug report didn't show what was wrong; I can see nothing wrong; +> bug reporter cannot seem to remember what was wrong. Probably user error. +> --[[Joey]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment new file mode 100644 index 000000000..45be25186 --- /dev/null +++ b/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment @@ -0,0 +1,21 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-11-16T19:04:37Z" + content=""" +Seems to work as described here: + + joey@darkstar:~/tmp/r>rm localhost__joey_blog_index.html + joey@darkstar:~/tmp/r>git annex addurl --pathdepth 2 http://localhost/~joey/blog/index.html + addurl blog/index.html (downloading http://localhost/~joey/blog/index.html ...) + /home/joey/tmp/r/ 100%[===========>] 40.70K --.-KB/s in 0s + ok + (recording state in git...) + joey@darkstar:~/tmp/r>ls + blog/ + joey@darkstar:~/tmp/r>ls blog + index.html + +It would probably help if you can provide a test case where it does not work +as described. +"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment new file mode 100644 index 000000000..0cafc2a4d --- /dev/null +++ b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="CandyAngel" + avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" + subject="comment 4" + date="2016-11-25T20:27:07Z" + content=""" +I really don't know what to say. I can't even figure out which computer I updated git-annex on to test if it was still happening.. let alone reproduce it anymore. It does work fine. + +I'm so sorry to bother you with this, I've done something stupid! This is exactly why you ask for a transcript of bugs occurring. (Feel free to use this as an example for why you ask for them, so some good can come of it at least..). +"""]] diff --git a/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment b/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment new file mode 100644 index 000000000..a8469cfe0 --- /dev/null +++ b/doc/bugs/android__58___cannot_link_executable/comment_2_1057c0477050e52e463c36e03fcab09d._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="moc514@eb7af2cd9147722b29f32b6606feb2b8563dfac8" + nickname="moc514" + avatar="http://cdn.libravatar.org/avatar/c8c98fc66ef014e61c163375ca9e7422" + subject="Nexus 6p" + date="2016-12-16T02:08:21Z" + content=""" +I also have the same issue with the Nexus 6p with 7.1.1 +"""]] diff --git a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn new file mode 100644 index 000000000..5db40f4dd --- /dev/null +++ b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn @@ -0,0 +1,78 @@ +### Please describe the problem. + +annex add seems to ignore content under directories having . prefix. + +We thought to unify (across direct/indirect/v6) adding files to annex repository by using 'git annex add' with corresponding setting for largefiles for any addition, but it seems to ignore content under .-prefixed directories, unlike git + +### What version of git-annex are you using? On what operating system? + +6.20161122+gitg9f179ae-1~ndall+1 + +### Please provide any additional information below. + +[[!format sh """ +hopa:/tmp/datalad_temp_test_annex_add_no_dotfilesqMXck8 +$> git status +On branch master + +Initial commit + +nothing to commit (create/copy files and use "git add" to track) + +$> mkdir .dir dir; echo 123 > .dir/123; echo 124 > dir/124 + +$> git status +On branch master + +Initial commit + +Untracked files: + (use "git add <file>..." to include in what will be committed) + + .dir/ + dir/ + +nothing added to commit but untracked files present (use "git add" to track) + +$> git annex add -c 'annex.largefiles=nothing' . +add dir/124 (non-large file; adding content to git repository) ok +(recording state in git...) + +$> git status +On branch master + +Initial commit + +Changes to be committed: + (use "git rm --cached <file>..." to unstage) + + new file: dir/124 + +Untracked files: + (use "git add <file>..." to include in what will be committed) + + .dir/ + + +# and with regular git +$> git -c 'annex.largefiles=nothing' add . + +$> git status +On branch master + +Initial commit + +Changes to be committed: + (use "git rm --cached <file>..." to unstage) + + new file: .dir/123 + new file: dir/124 + + +"""]] + +Ref: https://github.com/datalad/datalad/issues/1027 + +[[!meta author=yoh]] + +[[done]]; oh -- it is RTFM: --include-dotfiles --[[yoh]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment new file mode 100644 index 000000000..327b63469 --- /dev/null +++ b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment @@ -0,0 +1,30 @@ +[[!comment format=mdwn + username="https://launchpad.net/~felixonmars" + nickname="felixonmars" + avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" + subject="comment 1" + date="2016-11-28T04:17:12Z" + content=""" +aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet: + +``` +[ 95 of 544] Compiling Utility.Url ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o ) + +Utility/Url.hs:354:34: error: + * The constructor `StatusCodeException' should have 2 arguments, but has been given 3 + * In the pattern: StatusCodeException s _ _ + In an equation for `matchStatusCodeException': + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing + +Utility/Url.hs:354:34: error: + * Couldn't match expected type `HttpException' + with actual type `HttpExceptionContent' + * In the pattern: StatusCodeException s _ _ + In an equation for `matchStatusCodeException': + matchStatusCodeException want e@(StatusCodeException s _ _) + | want s = Just e + | otherwise = Nothing +``` +"""]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment new file mode 100644 index 000000000..ada283d8b --- /dev/null +++ b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-12-13T15:58:25Z" + content=""" +This got fixed in the meantime. Note that posting comments to a bug that +has already been closed is a good way to get new problems not to be +noticed.. +"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment new file mode 100644 index 000000000..9cf3695f5 --- /dev/null +++ b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="http://svario.it/gioele" + nickname="Gioele" + avatar="http://cdn.libravatar.org/avatar/af2f2ba0dafe4650011d20f2168d43cff773aba97f55ae5b252bb873f391c1e2" + subject="compiled with GHC 8, but LOCPATH is still set" + date="2016-12-21T21:51:09Z" + content=""" +This bug does not want to die. + +The current standalone build (`6.20161211-gc3ab3c668`) has been compiled with GHC 8 but when I launch `runshell`, I still see that `LOCPATH` is set and the character encoding is messed up. + +I deduced the version of GHC used to compile git-annex with `strings ./shimmed/git-annex/git-annex | grep 'GHC [0-9]'`. +"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment new file mode 100644 index 000000000..1942a6f52 --- /dev/null +++ b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2016-12-24T16:57:45Z" + content=""" +This is an old closed bug report. The recent comments are about a +completely unrelated issue, which I suspect was fixed by +[[!commit 95c8b37544c383983712c5c368dd803c51bf8eeb]]. + +Please file new bug reports if you have an issue, if the old bug report was +closed years ago. +"""]] diff --git a/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn b/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn new file mode 100644 index 000000000..75a546159 --- /dev/null +++ b/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn @@ -0,0 +1,34 @@ +### Please describe the problem. +directory 1.3.0.0 causes a conflict for "getFileSize" + +### What steps will reproduce the problem? +Build git-annex with directory 1.3.0.0 (first need to bump max directory version on concurrent-output (and aws if building with s3)) + +### What version of git-annex are you using? On what operating system? +6.20161210 on macOS 10.11 El Capitan + + +### Please provide any additional information below. + +[[!format sh """ +[23 of 34] Compiling Common ( Common.hs, dist/setup/Common.o ) + +Common.hs:3:16: error: + Conflicting exports for ‘getFileSize’: + ‘module X’ exports ‘X.getFileSize’ + imported from ‘Utility.Directory’ at Common.hs:28:1-29 + (and originally defined in ‘System.Directory’) + ‘module X’ exports ‘X.getFileSize’ + imported from ‘Utility.FileSize’ at Common.hs:34:1-28 + (and originally defined at Utility/FileSize.hs:26:1-11) +"""]] + +A fix, though possibly not best, is to make this change in Common.hs: +[[!format sh """ +import Utility.Directory as X hiding (getFileSize) +"""]] + +### 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) +Yes :) + +> [[fixed|done]]; thanks for reporting! diff --git a/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn b/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn new file mode 100644 index 000000000..80193cd54 --- /dev/null +++ b/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn @@ -0,0 +1,28 @@ +### Please describe the problem. +I tried to use `git-annex-fsck --all --from remote` to check files on a special remote, but git-annex did a scan of the local repo instead. If I don't use the `--all` flag, it correctly checks the files on the remote (but just the files in the current checked out branch). + +### What steps will reproduce the problem? + mkdir repo + mkdir special + cd repo + git init + git annex init + git annex initremote special type=directory directory=../special encryption=none + touch testfile + git annex add testfile + git annex copy testfile --to special + chmod -R +w ../special/* + rm -r ../special/* + git annex fsck --all --from special # should check special remote but checks local repo instead + git diff git-annex^ git-annex # activity log shows that it checked special remote + git annex fsck --from special # correctly checks special remote, identifies missing file + + +### What version of git-annex are you using? On what operating system? +6.20161012 on Ubuntu 16.10 + +### Have you had any luck using git-annex before? +Yes, it's been very helpful for managing large files between laptops, desktops, external storage, and remote storage. + +> Thanks for an excellent test case and a clear bug report. I've fixed this +> bug. [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn new file mode 100644 index 000000000..e544015a6 --- /dev/null +++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn @@ -0,0 +1,38 @@ +### Please describe the problem. + +I'm sending a stream of keys and filenames to git-annex fromkey on stdin, and it errors out with "git-annex: <stdin>: hGetContents: invalid argument (invalid byte sequence)". On the other hand yipdw tried to reproduce this and it worked fine for him, so I must be doing something wrong. + +I have LANG=en_US.UTF-8 set in my environment, if that matters. + +### What steps will reproduce the problem? + +[[!format sh """ +echo "MD5-s3263532--0b4d070eff7baa8ef314ca330aecb71f é" | git-annex fromkey +"""]] + +### What version of git-annex are you using? On what operating system? + +[[!format sh """ +git-annex version: 6.20161118-g0a34f08 +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 +local repository version: 5 +supported repository versions: 3 5 6 +upgrade supported from repository versions: 0 1 2 3 4 5 +operating system: linux x86_64 +"""]] + +### Please provide any additional information below. + +Note that this is indeed valid utf-8: + +[[!format sh """ + db48x ~ projects IA.BAK-server echo "é" | hexdump -C +00000000 c3 a9 0a |...| +00000003 +"""]] + +> Despite my strange inability to reproduce these, there's really only one +> thing that can fix it, namely using fileEncoding. Now done for all batch +> and stdin reading stuff. [[fixed|done]] I suppose. --[[Joey]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment new file mode 100644 index 000000000..a0409e281 --- /dev/null +++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment @@ -0,0 +1,55 @@ +[[!comment format=mdwn + username="alpernebbi" + avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" + subject="UTF-8 problems in some other commands" + date="2016-12-05T20:46:07Z" + content=""" +Running the command above gives me the same error on Xubuntu 16.04, using `git-annex-standalone` package from NeuroDebian repositories. + + git-annex version: 6.20161122+gitg9f179ae-1~ndall+1 + 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 + local repository version: 5 + supported repository versions: 3 5 6 + upgrade supported from repository versions: 0 1 2 3 4 5 + operating system: linux x86_64 + +I encountered other commands that fail as well: + + $ touch u.txt ü.txt + $ git annex add + + $ git-annex calckey ü.txt + # prints key + + $ git-annex calckey --batch + ü.txt + # dies + + $ git-annex lookupkey ü.txt + # prints key + + $ git-annex lookupkey --batch + ü.txt + # dies + + $ git-annex metadata --batch --json + {\"file\":\"ü.txt\"} + # dies + + $ git-annex metadata --batch --json + {\"file\":\"u.txt\",\"fields\":{\"ü\":[\"b\"]}} + # dies + + $ git-annex metadata --batch --json + {\"file\":\"u.txt\",\"fields\":{\"a\":[\"ü\"]}} + # dies + +All those die without output, all $? are 0. +No values were recorded to metadata. +Also: + + $ git-annex-metadata --json + # entry for \"ü.txt\" has \"file\":\"��.txt\" +"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment new file mode 100644 index 000000000..0b2cabdf9 --- /dev/null +++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment @@ -0,0 +1,31 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-12-08T21:03:14Z" + content=""" +I'm not able to reproduce the original reported problem; it works even when +using the C locale. However, it may be that this patch would fix it: + +<pre> +diff --git a/Command/FromKey.hs b/Command/FromKey.hs +index dca63aa..6a81c1f 100644 +--- a/Command/FromKey.hs ++++ b/Command/FromKey.hs +@@ -45,7 +45,9 @@ startMass = do + next massAdd + + massAdd :: CommandPerform +-massAdd = go True =<< map (separate (== ' ')) . lines <$> liftIO getContents ++massAdd = do ++ liftIO $ fileEncoding stdin ++ go True =<< map (separate (== ' ')) . lines <$> liftIO getContents + where + go status [] = next $ return status + go status ((keyname,f):rest) | not (null keyname) && not (null f) = do +</pre> + +(The NeuroDebian git-annex-standalone may well have had its locale +installation broken by [[!commit c07981122672f6cc87ca08efb57d8a7b1e2f5725]], +which assumes that the git-annex.linux is writable by the user. +I doubt that is related to the original bug report.) +"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment new file mode 100644 index 000000000..5011aa1fa --- /dev/null +++ b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="alpernebbi" + avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" + subject="comment 3" + date="2016-12-10T07:36:04Z" + content=""" +I experienced all these with the [linux standalone](https://git-annex.branchable.com/install/Linux_standalone/) from this site as well. + +However, I couldn't reproduce them in a Debian unstable chroot where I installed the `git-annex` package from their repos. +"""]] diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment new file mode 100644 index 000000000..493031115 --- /dev/null +++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_8_48026cf7c187e97d53d15d35ed2c3670._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 8""" + date="2016-11-16T21:48:49Z" + content=""" +The arm daily build now uses a 32kb page size. So try +<https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz> + +That has been verified to fix the problem on a Drobo 5N. + +This may still not be enough for some of the affected NAS devices, which +use a 64kb page size. Unfortunately, gold fails to link with a 64kb page +size: <http://bugs.debian.org/844467> +"""]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn index eb961030c..f4339bff7 100644 --- a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn +++ b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn @@ -65,3 +65,5 @@ I would just like to be sure nothing else is hidden. > .git/config to remove that in order to recover from the problem, so might > as well remove `.git/annex/ssh_config` too. > --[[Joey]] + +>> Fixed more by stopping using `.git/annex/ssh_config` at all. --[[Joey]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment new file mode 100644 index 000000000..42550d51f --- /dev/null +++ b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9" + nickname="scottgorlin" + avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563" + subject="IgnoreUnknown Include considered harmful?" + date="2016-11-23T20:07:45Z" + content=""" +As noted, include appears to not work on a mac at the moment. This means git-annex silently ignores the included configs, which may be required to ssh to the remotes of interest. This is happening to me. + +My understanding is that ssh aliases are the recommended way of juggling multiple private keys amongst multiple hosts, so it is a required part of many git workflows. In this particular case, I have set up git annex on a NAS which does not allow multiple ssh users (QNAP) and the authentication is done only via key identity, not username. Thus, host aliases are necessary. + +If one config can't include another, I would prefer an early failure indicating a problem with the config file, or better, a solution where git-annex doesn't require a config. In this scenario, git fetch remote_name and git annex copy --to remotename do not resolve to the same alias definitions (the latter is missing because of the ignored config!). + +I got my setup to work only by finding and manually editing <repo>/.git/annex/ssh_config, which to my knowledge is undocumented (ie when is it written? do any commands change it?); manual mucking around inside .git to me is not a good practice, and for now I have two different alias's defined (in repo and in ~/.ssh/config) + + +"""]] diff --git a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment new file mode 100644 index 000000000..566926a32 --- /dev/null +++ b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="palday@91f366b5178879146d2b6e1e53bfa21389ee89a8" + nickname="palday" + avatar="http://cdn.libravatar.org/avatar/077a63af75ddba159980fbf88690f401" + subject="Temporary workaround until the brew formula is updated" + date="2016-11-29T02:17:52Z" + content=""" +The homebrew formula doesn't yet this fix, but you can get around the problem in the meantime by getting a newer SSH via homebrew: + +``` +brew install homebrew/dupes/openssh +``` + +You can then choose to keep that or get rid of it when the formula for git annex is later updated. +"""]] diff --git a/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn new file mode 100644 index 000000000..20878cb21 --- /dev/null +++ b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn @@ -0,0 +1,30 @@ +### Please describe the problem. + +The OpenSSH client parses configuration in a "first match wins" manner, and this also applies to `IgnoreUnknown`. This means that when git-annex's `Include ~/.ssh/config` is processed, any user-specified `IgnoreUnknown` setting in the global configuration will be ignored because it has already been set. As a result, every time git-annex runs ssh, it immediately exits with an error: + +[[!format text """ +drop vol3 somefile.mkv (locking vol5...) (lockcontent failed) (checking vol5...) +/home/grawity/.ssh/config: line 217: Bad configuration option: gssapikeyexchange +/home/grawity/.ssh/config: terminating, 1 bad configuration options +failed +"""]] + +To be fair, this might be an OpenSSH bug (IgnoreUnknown ought to be merged), but it seems git-annex is triggering it unnecessarily. + +### What steps will reproduce the problem? + +1. In `~/.ssh/config`, have some unrecognized options (e.g. `GSSAPIKeyExchange`) and a corresponding `IgnoreUnknown`. + +2. Try to use a git-annex feature which directly invokes ssh, e.g. get or drop. + +### What version of git-annex are you using? On what operating system? + +6.20161210 on Arch, but I think this was introduced in a 201611* release. + +### 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) + +Yes, it's been taking care of my archives for nearly a year. + +> How annoying, ssh seems to make it impossible to set this in a way that +> doesn't break some configurations. Oh well, gave up on setting it +> and removed the code to do so. [[done]] --[[Joey]] diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn new file mode 100644 index 000000000..ca5b86c87 --- /dev/null +++ b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn @@ -0,0 +1,10 @@ +### Please describe the problem. +https://git-annex.branchable.com/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/ deal with Include not being supported by pre 7.3 by using the 6.4+ IgnoreUnknown directive. + +Unfortunately, the Android apk (which I got from https://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk) has (according to ssh -v) OpenSSH_6.0p1. + +I had to edit .git/annex/ssh.config to comment out the three offending lines and then append the contents of ~/.ssh/config to get git-annex working again. + +(This is on a Nexus 10 running stock, though I doubt it matters) + +> Reverted use of this feature for now.[[done]] --[[Joey]] diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment b/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment new file mode 100644 index 000000000..0cf33b8b3 --- /dev/null +++ b/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-08T21:11:31Z" + content=""" +Indeed, the ssh bundled in the apk is shockingly old by now, and needs to +get updated. +"""]] diff --git a/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn b/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn new file mode 100644 index 000000000..dd491e5fd --- /dev/null +++ b/doc/bugs/unRAID_shares_treated_as_a_crippled_filesystem.mdwn @@ -0,0 +1,46 @@ +### Please describe the problem. + +Running `git annex init` on an [unRAID server](https://lime-technology.com/what-is-unraid/) results in an annex created with `crippledfilesystem = true` and `direct = true`. I understand from reading [this](https://git-annex.branchable.com/design/assistant/blog/day_188__crippled_filesystem_support/) that it occurs when `git annex init` performs a probe to determine if all of the following are supported: + +1. symlinks +2. hard links +3. unix permissions + +Although unRAID disks are formatted with xfs, and therefore support all three of the above, I'm assuming that unRAID's method of combining multiple disks into one "share" is the cause of the problem (hardlinks still work on a single disk, but not on shares that span multiple disks). Symlinks and unix permissions work normally in the unRAID-created shares. + +Is there any way to allow the use of 'indirect' mode with multi-disk shares? As I mentioned, symlinks and unix permissions work normally--it's only the hardlinks that won't work across the multi-disk shares. + +I can create a 'normal' annex as long as I `cd` to a single disk drive first--what would happen if the annex was later moved onto a multi-disk share? Would it still work? Would it fail gracefully? Would it cause data loss? + +### What steps will reproduce the problem? + + cd /mnt/user/NameOfShare + git init + git annex init + +The following will result in the creation of a 'normal' indirect share: + + cd /mnt/disk1 + git init + git annex init + +### What version of git-annex are you using? On what operating system? + + git-annex version: 6.20161211-gc3ab3c668 + 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 p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external + +### 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. +"""]] + +### 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) + +Has been working great, so far, except for the above. diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn new file mode 100644 index 000000000..6cd90264c --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn @@ -0,0 +1,31 @@ +### Please describe the problem. +Recent builds of git-annex spew out many lines such as: + + git-annex: unable to decommit memory: Invalid argument + git-annex: unable to decommit memory: Invalid argument + git-annex: unable to decommit memory: Invalid argument + git-annex: unable to decommit memory: Invalid argument + git-annex: unable to decommit memory: Invalid argument + +### What steps will reproduce the problem? +This happens to me syncing any large repository now. + +### What version of git-annex are you using? On what operating system? +git-annex version: 6.20161118-g0a34f08 + +uname -r: 4.4.14-11.pvops.qubes.x86_64 + +/etc/system-release: Fedora release 23 (Twenty Three) + +### Please provide any additional information below. + +I found this: https://ghc.haskell.org/trac/ghc/ticket/12495 + +It looks like this is a problem that occurs only on kernels < 4.5, when ghc is built with a newer glibc, I think. + +### 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) + +Git annex rocks! + +> [[fixed|done]]; fix is confirmed, all linux standalone builds are updated +> (and I pinged Yoh to update the neurodebian standalone build). --[[Joey]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment new file mode 100644 index 000000000..15dde50f8 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 10""" + date="2016-12-19T19:53:11Z" + content=""" +The only way the files could be in lost+found is if the system crashed or +there was a disk error etc. Can't be due to this bug. So, it may be that +this bug did not actually cause any data loss. The screwed up symlinks could +have been caused by a disk error. +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment new file mode 100644 index 000000000..3fe7af8dd --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="Corrupt Links Produced, Significant Data Loss" + date="2016-12-10T12:31:31Z" + content=""" +Additionally, I added a mess of files with this release of git-annex, and of the 200 files added, three of the links produced were corrupt. I'm still searching for where these files have gone to recover the data. + +The files look like this in `ls -l`, they were bup files: + + lrwxrwxrwx 1 user user 338 Jun 17 22:36 bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> *??:?;J????????? + lrwxrwxrwx 1 user user 336 Jun 17 21:41 bup.git/objects/pack/pack-4d202b3929b187d4acaf1602526e7344eef1edc8.pack -> ?p???GWj??????ܥ??{b?#???>C??%??????~à???/hjT;?p??d?8??oyE?K?)6?uL+??h??&???SB}?'s??֫{?>^i?&?f??^{ш??aD??t4?C?sBTk>d6H???5h3?ڋ6fAa??=?r????j?????a8K??????????B?~????I͕?T7?Y??=???b?7C???鋤??8???\"?????#???M?????}z?A??9?C>?-?GD??7?ј;'P?H??ɑ??Zr?/U???W?G??3@\"??Ȧ?z?h???U??Ԇ???R??u??I????62??>@??@?a??x???}?????)d?G;(???m_?^3?????T + lrwxrwxrwx 1 user user 332 Jul 20 07:32 bup.git/objects/pack/pack-5328381f3b023c1356581c22d1e74d4eda0b46a3.idx -> c??'w??????????m?q#?ٱCO??o????ʃ?Ʃڌ??[???Ѐ??*?;.?c?N?0?????D$ o?r????8BGn?96gY?B?Z1?=???{??z?71????!aG?>?u)???i\?G[???:?Kk??%??.mu???n???K??ǚ????q&Z-?E???]??/?6???} +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment new file mode 100644 index 000000000..52932cd5e --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2016-12-10T15:13:44Z" + content=""" +I think that the "x86-32, for ancient kernels" build should avoid this +problem. <http://git-annex.branchable.com/install/Linux_standalone/> + +It's very surprising if this lead to symlinks being created that apparently +contain garbage in their link targets. Perhaps glibc is failing in a way +with the old kernel that leads to memory corruption? I have asked the GHC +developers if that could be the case in +<https://ghc.haskell.org/trac/ghc/ticket/12865> + +I hope that the content of your files is in fact somewhere under +`.git/annex/objects/` -- look around, and with some luck, you may find it. +Unfortunately, the information about, which object file goes with which +working tree has apparently been lost. (Also, you might check if these +symlinks have been staged in git; it's possible though unlikely that the +correct link target got staged in git.) + +I have filed a bug on Debian's ghc to get them to fast-track getting the +patch into ghc. <https://bugs.debian.org/847677> +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment new file mode 100644 index 000000000..b5316c0de --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="comment 3" + date="2016-12-11T00:26:41Z" + content=""" +Thank you so much for the prompt response. My system wouldn't shut down cleanly after this, either, so there may have been something else screwy going on. Still, I'll be using the build for ancient kernels exclusively for the near future. Thank you. +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment new file mode 100644 index 000000000..7aea3d6af --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 3""" + date="2016-12-11T19:35:21Z" + content=""" +All Linux standalone builds have been updated with a version of ghc that +has that bug fixed. Can you please upgrade and verify it's fixed? +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment new file mode 100644 index 000000000..801f70223 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="Verification" + date="2016-12-11T00:59:50Z" + content=""" +I saw the new comment on the download page and tried running `git annex test`. I can confirm that `git annex test` eventually segfaults using the normal build on my system, whereas it passes successfully using the 'ancient kernels' build. The version strings output for the two are identical. +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment new file mode 100644 index 000000000..9dec23b00 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="Nope a Fluke" + date="2016-12-11T13:26:29Z" + content=""" +Apologies. I can't reproduce the segfault running the tests again. The corruption and crashing seems to have been some horrifying fluke. +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment new file mode 100644 index 000000000..08e3364ca --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 7""" + date="2016-12-12T17:30:03Z" + content=""" +Can you please check if the current builds still have the "unable to +decommit memory" problem or not? + +(What it does after that error is probably nondeterministic, fixing that +error is the crucial thing.) +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment new file mode 100644 index 000000000..6d8994155 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="comment 8" + date="2016-12-13T15:52:34Z" + content=""" +It looks like the errors are gone. Thank you so much. +"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment new file mode 100644 index 000000000..42a14f12a --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="xloem" + avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" + subject="Coda" + date="2016-12-18T14:56:17Z" + content=""" +The missing files turned up in 'lost+found' the next time I ran fsck =) +"""]] diff --git a/doc/bugs/wget_always_shows_progress_bar.mdwn b/doc/bugs/wget_always_shows_progress_bar.mdwn new file mode 100644 index 000000000..708db8906 --- /dev/null +++ b/doc/bugs/wget_always_shows_progress_bar.mdwn @@ -0,0 +1,25 @@ +### Please describe the problem. + +git annex addurl or importfeed operations were quiet on git-annex versions older than 5.20141219, if +annex.web-options was set to "--quiet". But now the --show-progress option is always passed to wget. + +In some use cases this might be nice, but I'm using GNU Parallel to update multiple podcast feeds +concurrently, and it causes wget to output the ugly "dot" indicator for every feed, which is totally +useless since parallel buffers and groups the output. Adding "--no-show-progress" to web-options +does not help (it does not override --show-progress), nor does redirecting stdout to /dev/null. +Redirecting stderr would hide possible errors. + +### What steps will reproduce the problem? + +parallel git annex importfeed --relaxed --quiet ::: http://feeds.feedburner.com/freakonomicsradio + +### What version of git-annex are you using? On what operating system? + +5.20151208-1~bpo8+1 on Debian. + +### 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 love git annex and use it daily. + + +> [[done]] --[[Joey]] diff --git a/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment b/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment new file mode 100644 index 000000000..c2e6eb53f --- /dev/null +++ b/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-12-13T15:49:20Z" + content=""" +Since 2014, git-annex has used wget -q --show-progress to get a +progress bar without the several other lines of output it would normally +display. Whether a given git-annex build does this depends on what +version of wget it saw at configure time. + +Running git-annex with --quiet will disable the wget progress bar (and +other git-annex output). This seems like the thing to do if you're running +git-annex concurrently. (Of course, git-annex also has its own built-in +concurrency with -J which can display multiple download progress bars in a +nice way.) + +Still, might as well make the web-options come after the default options so +they can be overridden. Doing so. +"""]] diff --git a/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn b/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn new file mode 100644 index 000000000..19e839263 --- /dev/null +++ b/doc/bugs/when_you_get_a_file_but_don__39__t_actually_have_enough_space_for_it__44___the_error_message_makes_useless_suggestions.mdwn @@ -0,0 +1,21 @@ +The suggestion to make remotes available isn't really applicable, since the error was local. + +This is with git annex 6.20161110-gd48f4ca. + +[[!format sh """ + ../git-annex.linux/git-annex get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml +get archiveteam-fire/metro.co.uk-urls-2007-04-12-20150627/metro.co.uk-urls-2007-04-12-20150627_meta.xml + not enough free space, need 98.82 GB more (use --force to override this check or adjust annex.diskreserve) + + Unable to access these remotes: web + + Try making some of these repositories available: + 00000000-0000-0000-0000-000000000001 -- web + 9f8218c0-763f-463d-9152-ecdc56d4452c -- iabak@redwyne.jwintjen.de:~/IA.BAK/shard12 +failed +git-annex: get: 1 failed +"""]] + +### 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) + +mixed success |