summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar xloem <xloem@web>2016-05-23 10:55:54 +0000
committerGravatar admin <admin@branchable.com>2016-05-23 10:55:54 +0000
commit10917130d061a7e05a923ac3877b6a0026bc566a (patch)
treeed96488b50fab8583d5f7f5971a875a03a4bb043
parent308976a38babc27d3db062b2b77087d3fe1c84d0 (diff)
-rw-r--r--doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn90
1 files changed, 90 insertions, 0 deletions
diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
new file mode 100644
index 000000000..35adfb2d6
--- /dev/null
+++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+In my repo network, multiple repos are cropping up with an "invalid object" error. The object in question changes and appears to be from git-annex's hidden branch.
+
+### What steps will reproduce the problem?
+This is happening after I add a mess of new files and sync, within a couple times of doing this, after a day or so.
+
+### What version of git-annex are you using? On what operating system?
+6.20160518-g766728c on linux
+
+### Please provide any additional information below.
+
+[[!format sh """
+# Example error, file in question will change
+ (recording state in git...)
+ error: invalid object 100644 d547f60ac6c53f8bf38999d93ce954e3dfca1656 for
+ '051/0b4/SHA3_512-s12447441634--b84ff2ead694b9d355d8deb4eae620b5979f0127f127718d53d02cd32f1020fba45f1e63723484462beb10110328dab29d875ea1788f949ce541640603fa73c0.log'
+ fatal: git-write-tree: error building trees
+ git-annex: failed to read sha from git write-tree
+# End of transcript or log.
+
+# log of attempting to determine the issue yesterday
+2016-05-22
+
+Issue history:
+Original annex started being unable to finish commit.
+Second annex, I cloned and copied objects folder over. Soon, same issue.
+Third annex, cloned from elsewhere, use git annex get to get objects from
+broken repo. Same issue developed.
+Fourth annex, cloned from elsewhere, was able to commit successfully
+prior to adding objects from broken repo.
+Some object in the broken repo seems to be causing this issue somehow.
+
+Plan to resolve:
+- copy all objects over again. verify that issue immediately develops.
+
+ I expect the issue will trigger when I add a set of objects with litelog.
+ So I could narrow it either by narrowing the objects I add with litelog,
+ or by narrowing the object I copy from the broken repo.
+
+ I'll narrow the issue between the two, first.
+
+annex: used to be annex.2, busted
+annex.3: third repository, busted, holds objects
+annex.4:
+ 1. cloned from delta
+ 2. added logs, no issue
+ 3. 10:24:24 EDT rsync --delete-during'd objects in from annex.3
+ 4. 10:25:10 EDT added small test file, sync'd with delta fine
+ 5. 2016-05-22 10:27:38
+ I ran fetchall but ran by root by mistake.
+ files were added with wrong permissions
+ fixed permissions. only two files were cpied, voicerecorder and muse.
+ sync works fine.'
+ 6. ran fetchall (as root) again, got 4 sensorium files
+ 7. add and sync seems to work fine.
+ So now this repository is functioning with additional objects copied into
+ its annex folder. It must have been something else which caused the issue
+ on the other repo I initialized this way.
+ 8. I foolishly tried to git annex add the alphabetically first object from
+ the annex/objects folder to get it annex's logs. It failed when trying to
+ _delete_ it to replace it with a link to itself, luckily it was not writable.
+
+ I'll try using this repo - 2016-05-22 10:36:24 EDT
+
+ I'll add the remotes one at a time and sync with them, adding litelog after
+ each one.
+
+ 9. 2016-05-23 00:08 EDT
+ Issue reoccurred uploading data from phone. Was a larger block of data.
+ First fetched
+ then added
+ then copied to delta
+ issue showed at end of copy to delta
+
+ perhaps the issue resides on delta ??? but we synced to delta fine before
+ the issue must happen over time while I am away from the computer
+ or respond to a large amount of logs being uploaded
+ or it could have happened as a result of my work on the nested repo
+ 10. 2016-05-23 00:10:15 EDT
+ $ git annex copy --to=gitlab
+ 06:55 EDT
+ $ git annex sync gitlab
+ both commands ran without issue
+ delta also fsck'd fine
+
+"""]]
+
+### 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)
+Very stable. Still excited.
+