summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar GLITTAH <GLITTAH@web>2013-05-08 12:15:15 +0000
committerGravatar admin <admin@branchable.com>2013-05-08 12:15:15 +0000
commit55547adfe4acb2ba35f9a19192f2d3aaa9ed80a2 (patch)
treec8274410e68006c7afff32daf0fb2500361d9ea3
parent5e2a7f688abe2a4ad2bdf5db7a9615cfa8852c77 (diff)
-rw-r--r--doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn7
1 files changed, 7 insertions, 0 deletions
diff --git a/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn b/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn
new file mode 100644
index 000000000..872e7d53d
--- /dev/null
+++ b/doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn
@@ -0,0 +1,7 @@
+Out of simple curiosity, how does 'git annex migrate' work? I'm mostly wondering how file integrity is ensured.
+
+Let's say you want to migrate foo.txt from (say) md5 to sha256. Does git annex simply sha256sum foo.txt and rename it in the .git/objects folder to the new sum? Or does it md5sum foo.txt, verify that it's the not corrupt, then sha256sum it and rename to the new sum?
+
+You could run into problems if you migrate without first verifying; if the file is corrupt and you simply sha256sum and rename it, then the file wouldn't seem corrupt at your next fsck.
+
+I'm sure you've considered this during the basic design phase of git-annex, but I'd just like to be sure. I'm kind of paranoid when it comes to data integrity. =P