diff options
author | 2013-05-08 12:15:15 +0000 | |
---|---|---|
committer | 2013-05-08 12:15:15 +0000 | |
commit | 55547adfe4acb2ba35f9a19192f2d3aaa9ed80a2 (patch) | |
tree | c8274410e68006c7afff32daf0fb2500361d9ea3 | |
parent | 5e2a7f688abe2a4ad2bdf5db7a9615cfa8852c77 (diff) |
-rw-r--r-- | doc/forum/Does_migrate_ensure_data_integrity__63__.mdwn | 7 |
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 |