diff options
Diffstat (limited to 'doc/bugs')
5 files changed, 147 insertions, 0 deletions
diff --git a/doc/bugs/bup_initremote_failed_with_localhost_+_username.mdwn b/doc/bugs/bup_initremote_failed_with_localhost_+_username.mdwn new file mode 100644 index 000000000..d354c8eb1 --- /dev/null +++ b/doc/bugs/bup_initremote_failed_with_localhost_+_username.mdwn @@ -0,0 +1,47 @@ +### Please describe the problem. +Attempted to create a bup remote on the current system via ssh. It appears to have created the bup remote fine, but fails when sshing to it and does not add the remote. +This is a normal indirect annex (currently containing a single test jpg in its root) +I'm presuming the error is "(storing uuid...) sh: 1: cd: can't cd to /~/archie" + + +### What steps will reproduce the problem? +git annex initremote bup type=bup encryption=none buprepo=sshservername:path + +I've tried using .ssh/config to remove the username from the servername passed to bup repo and it still fails. + +### What version of git-annex are you using? On what operating system? +[[!format sh """ +>git-annex version +git-annex version: 4.20130615-g29d5bb9 +build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP DNS +local repository version: 3 +default repository version: 3 +supported repository versions: 3 4 +upgrade supported from repository versions: 0 1 2 +"""]] +debian wheezy i686 + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + +> git annex initremote bup type=bup encryption=none buprepo=bup@localhost:archie +initremote bup (bup init...) +Reinitialized existing Git repository in /media/backup/home/archie/.bup/ +Initialized empty Git repository in /media/backup/bup/archie/ +(storing uuid...) sh: 1: cd: can't cd to /~/archie +git-annex: ssh failed + +> ssh bup@localhost +Last login: Mon Jun 17 10:35:45 2013 from localhost +$ ls +archie +$ cd archie +$ ls +branches config description HEAD hooks info objects refs + + +# End of transcript or log. +"""]] diff --git a/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_1_c2092add1430667108a3fdc5e1c9b5f5._comment b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_1_c2092add1430667108a3fdc5e1c9b5f5._comment new file mode 100644 index 000000000..52bb21ae3 --- /dev/null +++ b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_1_c2092add1430667108a3fdc5e1c9b5f5._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-06-15T18:50:45Z" + content=""" +Joe, you need to carefully read [[direct_mode]]. When you manually run `git merge` in a direct mode repository, you defeat associated file tracking, with the resulting behavior you describe. This is why there is a [[todo/direct_mode_guard]] todo item. +"""]] diff --git a/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_2_f0ea453951daf84dbddc653ac64822b6._comment b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_2_f0ea453951daf84dbddc653ac64822b6._comment new file mode 100644 index 000000000..2c45f6b58 --- /dev/null +++ b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_2_f0ea453951daf84dbddc653ac64822b6._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA" + nickname="Joe" + subject="comment 2" + date="2013-06-15T19:39:09Z" + content=""" +joey, Thank you for the reply. I have read that and also read about the direct mode guard. I only used git merge because I was stuck and didn't know what else to do. I assume the proper way to refresh my backup repo is to git annex sync. That's what's failing with the non-fast-forward error. I don't know what to do from there. Thank you for any help. +"""]] diff --git a/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_3_35a8be5ecc9d1b72c38f8ddb47678160._comment b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_3_35a8be5ecc9d1b72c38f8ddb47678160._comment new file mode 100644 index 000000000..c723d85bb --- /dev/null +++ b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_3_35a8be5ecc9d1b72c38f8ddb47678160._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA" + nickname="Joe" + subject="comment 3" + date="2013-06-16T13:27:36Z" + content=""" +Making some progress. It looks like it needs a .map file for the newly added file when I pull in the backup repo. I'm tracing the various places addAssociatedFile gets called. It looks like sync should do it. I think that's what sets up the map. If I copy the map file from another repo, I'm able to call get annex get foo2.txt. So the key is getting that map file created. +"""]] diff --git a/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_4_29e72997b88f91f84639587b4cede34c._comment b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_4_29e72997b88f91f84639587b4cede34c._comment new file mode 100644 index 000000000..c785ff77b --- /dev/null +++ b/doc/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/comment_4_29e72997b88f91f84639587b4cede34c._comment @@ -0,0 +1,76 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmhfodZquCI_EEl-f3h7HkROTszlsQL6yA" + nickname="Joe" + subject="comment 4" + date="2013-06-16T17:27:18Z" + content=""" +I have a workaround that requires a small patch. I'm not sure why it's not creating the mapping, but I noticed that git annex fsck has a verifyDirectMapping which will create the mapping if it doesn't exist. + +git annex fsck will throw an error on fixLinks and won't proceed to verifyDirectMapping if the map file doesn't exist. So, I needed a way to call verifyDirectMapping directly. My hack is to add an argument to git annex fsck to call verifyDirectMapping. + +My workflow is this: + +**repo1**: +[[!format sh \"\"\" +echo a > new.txt +git annex add . +git commit -m \"add a\" +git copy --to origin +git annex sync +\"\"\"]] + +**repo2**: +[[!format sh \"\"\" +git annex sync +git annex pull origin synced/master +git annex fsck --verifyDirectMapping +git annex get . +\"\"\"]] + +The new file comes down cleanly. + +I'm sure there's a better way to do this to fix the core issue, but here's how I patched Fsck.hs as a minimal workaround + +[[!format diff \"\"\" + +diff --git a/Command/Fsck.hs b/Command/Fsck.hs +old mode 100644 +new mode 100755 +index 9af6a4a..97aabb8 +--- a/Command/Fsck.hs ++++ b/Command/Fsck.hs +@@ -59,12 +60,16 @@ incrementalScheduleOption :: Option + incrementalScheduleOption = Option.field [] \"incremental-schedule\" paramTime + \"schedule incremental fscking\" + ++verifyDirectMappingOption :: Option ++verifyDirectMappingOption = Option.flag [] \"verifyDirectMapping\" \"verifies direct mappings are consistent\" ++ + options :: [Option] + options = + [ fromOption + , startIncrementalOption + , moreIncrementalOption + , incrementalScheduleOption ++ , verifyDirectMappingOption + ] + + seek :: [CommandSeek] +@@ -107,18 +112,23 @@ withIncremental = withValue $ do + start :: Maybe Remote -> Incremental -> FilePath -> (Key, Backend) -> CommandStart + start from inc file (key, backend) = do + numcopies <- numCopies file +- case from of +- Nothing -> go $ perform key file backend numcopies +- Just r -> go $ performRemote key file backend numcopies r ++ verify <- Annex.getFlag (Option.name verifyDirectMappingOption) ++ if verify ++ then go $ verifyDirectMapping key file ++ else ++ case from of ++ Nothing -> go $ perform key file backend numcopies ++ Just r -> go $ performRemote key file backend numcopies r + + +\"\"\"]] +"""]] |