comment
authorJoey Hess <joeyh@joeyh.name>
Tue, 28 Mar 2023 18:08:24 +0000 (14:08 -0400)
committerJoey Hess <joeyh@joeyh.name>
Tue, 28 Mar 2023 18:08:24 +0000 (14:08 -0400)
doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment [new file with mode: 0644]

diff --git a/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment b/doc/forum/Can_you_use_git_annex_on_gocryptfs__63__/comment_7_375b8234fc79d75f3cb39004cbe4d9e3._comment
new file mode 100644 (file)
index 0000000..c471d32
--- /dev/null
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2023-03-28T17:19:46Z"
+ content="""
+This is a filesystem bug. I reported it here:
+<https://github.com/rfjakob/gocryptfs/issues/724>
+
+`git-annex add` makes a hard link to the file and then stats the hard link
+before and after hashing. Due to this filesystem bug, it gets a different
+size.
+
+One workaround is:
+
+       git config annex.crippledfilesystem true
+
+Although setting annex.crippledfilesystem has other effects, including
+git-annex not locking down permissions of annexed files. So I don't know if
+I'd really recommend that workaround.
+
+It would be possible for git-annex to work around this by statting the file
+before making the hard link, rather than statting the hardlink after
+creation. But I don't think I want to work around filesystem breakage like
+that.
+"""]]