bug report

doc/bugs/v6_unlock_confused_by_touch.mdwn

@@ -0,0 +1,26 @@
+Touching a locked file in a v6 repository follows the symlink and touches
+the object file. This makes inAnnex's sameInodeCache fail because the keys
+database has a different mtime cached, and so `git annex unlock` doesn't
+populate the file with content, but with a pointer file.
+
+Also, `git annex` fsck complains no copies exist even though the symlink is
+pointing at a copy.
+
+This seems another reason to not check sameInodeCache for locked content,
+along with
+<http://git-annex.branchable.com/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/>
+--[[Joey]]
+
+Note that after initial  `git annex add` into a v6 repository, the keys
+database does not have an inode cached. But after an unlock followed by a
+lock, it does. So, here's a complete reproducer:
+
+	git annex init --version=6
+	date > file
+	git annex add file
+	git annex unlock file
+	git annex lock file
+	touch file
+	git annex unlock file
+	cat file
+	/annex/objects/...

doc/forum/Unlocking_files_gives_symlink_content/comment_1_f8032a5ea72f2cd833a626a197f94ba2._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2018-10-16T15:25:25Z"
+ content="""
+Please note that repository version 6, which you are using, is still experimental, it has
+known bugs and probably unknown bugs.
+
+I think this is an unknown bug, probably something has gotten inconsistent
+in the keys database and it doesn't realize it has the content.
+
+I found one way to cause this, filed a bug:
+[[bugs/v6_unlock_confused_by_touch]]
+"""]]

doc/todo/smudge.mdwn

@@ -29,6 +29,8 @@ git-annex should use smudge/clean filters. v6 mode
 
   I have this mostly analized and need to implement the planned fix.
 
+* <http://git-annex.branchable.com/bugs/>
+
 ## other warts
 
 * There are several v6 bugs that are edge cases and