comment

1 files changed, 24 insertions, 0 deletions

diff --git a/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_2_fe050712ea067df80f8d8c52d90d24d9._comment b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_2_fe050712ea067df80f8d8c52d90d24d9._comment
new file mode 100644
index 000000000..8d2e95161
--- /dev/null
+++ b/doc/bugs/git_annex_fsck_on_btrfs_devices/comment_2_fe050712ea067df80f8d8c52d90d24d9._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-05-27T19:10:48Z"
+ content="""
+Similar thing could happen on non-btrfs, if a disk sector
+is bad, or the disk has gone walkabout, you might get back an
+IO error reading it sometimes. And it could well be an intermittent error.
+
+`git annex fsck` already says "failed" and exits nonzero (immediately!)
+when this happens. It just doesn't move the file to the `bad` directory.
+
+I've improved the "sha1sum parse error" to instead be
+"sha1sum failed" in the case where the command exited nonzero.
+
+Moving everything to `bad` on what could be an
+intermittent error risks overkill. OTOH, if the whole disk is gone,
+it can make any changes it likes, it won't affect the actual disk. ;)
+
+On balance, I think fsck should assume that an IO error is something it
+should fix, and so it should move such files to `bad/`. With care taken to
+differentiate between a disk IO error and eg, a broken sha1sum command that
+fails to run, or a permissions problem reading the file, or whatever.
+"""]]