comment
authorJoey Hess <joeyh@joeyh.name>
Thu, 24 Feb 2022 17:10:40 +0000 (13:10 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 24 Feb 2022 17:10:40 +0000 (13:10 -0400)
doc/bugs/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_3_223df2a9cebd99a312537137863b1781._comment
doc/bugs/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment [new file with mode: 0644]

index 6c16581c1925c2e0bf3baaa16d25ca52b563d1f3..e7d69b6dc76accb78b8f5bf32ac3dc276444a5f8 100644 (file)
@@ -9,6 +9,11 @@ hook or no freeze hook), it still checks if the file's write permissions
 got removed.
 
 I think that, in order to support filesystems where chmod -w has no effect,
-init should skip looking at perms when there is a freeze hook. It can
+init should skip looking at write perms when there is a freeze hook. It can
 still check that freezing prevents writing to a file.
+
+Hmm, init uses checkContentWritePerm to see if the write permission is
+removed. That is also used by fsck, and when ingesting a file. So even if
+it were fixed in init, those would still be problems. This really needs to
+be fixed in checkContentWritePerm.
 """]]
diff --git a/doc/bugs/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment b/doc/bugs/can__39__t_make_annex_happy_in_freeze__47__thaw/comment_4_c78b91393ca917f9d231c39702c70e14._comment
new file mode 100644 (file)
index 0000000..0e97320
--- /dev/null
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-02-24T17:07:19Z"
+ content="""
+I think that this issue with drop freezing the content needs to be treated
+as a separate bug. There also may be a good reason for it to do it, I have
+not looked into that yet.
+"""]]