最近我提交了一分損壞的文件到資源庫上，被問到數(shù)據(jù)是否可恢復(fù)。根據(jù)提出的描述開始著手調(diào)查和修復(fù)問題，我認為其他人也會對解決的過程感興趣，或者遇到相同狀況后可以幫助到你。

我開啟了檢查(fsck)，發(fā)現(xiàn)問題出現(xiàn)在一個類上（我過去經(jīng)常用 $pack 和$obj 命令使得輸出可讀，而且因為我也更傾向于他們）：

$ git fsck 
error: $pack SHA1 checksum mismatch 
error: index CRC mismatch for object $obj from $pack at offset 51653873 
error: inflate: data stream error (incorrect data check) 
error: cannot unpack $obj from $pack at offset 51653873 

錯誤的信息意味著一個字節(jié)在某一個地方混亂了，推測是類里面描述過的（因為檢驗和的索引和zlib都失敗了）

通過閱讀zlib源代碼，我發(fā)現(xiàn)“檢查不正確數(shù)據(jù)”意味著adler-32

算法檢驗zlib數(shù)據(jù)末端沒有匹配已經(jīng)增加的數(shù)據(jù)。因此通過zlib壓縮數(shù)據(jù)是沒有用的，因為到每次末尾都會有錯誤，此時我們了也解到這個crc文件不能匹配。這個出錯的字節(jié)存在類文件的任何地方。

第一件事情我從packfile中pull出損壞的文件。我需要知道到底它多大的類，然后我發(fā)現(xiàn)了下面的信息：

$ git show-index <$idx | cut -d' ' -f1 | sort -n | grep -A1 51653873 
  
51653873 
51664736 

Show-index命令可以列出類和他們的偏移量。我們除了偏移量以外通通拋棄，然后排列，這樣我們感興趣的偏移量（這個位置是從上面fsck命令得出來的）是遵循下一個對象的偏移量?，F(xiàn)在我們知道類文件長度是10863字節(jié)，然后我們可以抓取它：

dd if=$pack of=object bs=1 skip=51653873 count=10863 

我檢查了文件的十六進制，搜索任何明顯的錯誤（例如，一個4K大小運行中的0是文件系統(tǒng)沖突很好的信號）。但是所有的地方看起來都很合理。

注意到“object”文件不適合被zlib直接壓縮；它本身包含git類信息頭，而且是可變長度的。我們想要去掉它，所以開始直接使用zlib操 作數(shù)據(jù)。你可以用你手工的方式（格式化信息的描述在Documentation/technical/pack-format.txt里面），或者你也可 以用debugger搞定它。我選擇了后者，創(chuàng)建了一個驗證的包如下：# pack magic and version

# pack magic and version 
printf 'PACK\0\0\0\2' >tmp.pack 
# pack has one object 
printf '\0\0\0\1' >>tmp.pack 
# now add our object data 
cat object >>tmp.pack 
# and then append the pack trailer 
/path/to/git.git/test-sha1 -b <tmp.pack >trailer 
cat trailer >>tmp.pack 

然后在debugger中運行”git index-pack tmp.pack” 命令（會停在unpack_raw_entry）。做到這里，我發(fā)現(xiàn)有3個自己的信息頭（信息頭本身有一個完整的類型和大?。?。然后我用下面語句去掉了這些內(nèi)容：

dd if=object of=zlib bs=1 skip=3 

我用一個自定義的C程序過的zlib的解壓鎖結(jié)果。但是它報錯了，我得到準確的輸出數(shù)字字節(jié)（也就是說，它匹配了上面解碼的git的信息頭大?。?。 但是”git hash-object” 命令的結(jié)果并沒有相同的shal值。所以現(xiàn)在仍然有一些錯誤的字節(jié)是我不知道的。這個文件發(fā)生在C源程序代碼， 我希望我能注意到一些明顯的錯誤，但是我沒有成功，我甚至都編譯成功了！

我也試過和在資源庫相同路徑下其他版本的文件作比較，希望有不一樣和不合理的部分。不幸運的是，這碰巧是唯一的修訂文件，在這個資源庫中。所以我沒有任何東西可以作比較。

于是我采取不同的措施，猜測著沖突是由限制單個字節(jié)引起的，我寫了交換每個字節(jié)的程序，是這解壓縮得到結(jié)果。因為這個類文件壓縮過后僅有10K，花了很多時間解壓出之后的結(jié)果是2.5M。

這是我用的程序：

#include <stdio.h> 
#include <unistd.h> 
#include <string.h> 
#include <signal.h> 
#include <zlib.h> 
  
static int try_zlib(unsigned char *buf, int len) 
{ 
  /* make this absurdly large so we don't have to loop */ 
  static unsigned char out[1024*1024]; 
  z_stream z; 
  int ret; 
  
  memset(&z, 0, sizeof(z)); 
  inflateInit(&z); 
  
  z.next_in = buf; 
  z.avail_in = len; 
  z.next_out = out; 
  z.avail_out = sizeof(out); 
  
  ret = inflate(&z, 0); 
  inflateEnd(&z); 
  return ret >= 0; 
} 
  
/* eye candy */ 
static int counter = 0; 
static void progress(int sig) 
{ 
  fprintf(stderr, "\r%d", counter); 
  alarm(1); 
} 
  
int main(void) 
{ 
  /* oversized so we can read the whole buffer in */ 
  unsigned char buf[1024*1024]; 
  int len; 
  unsigned i, j; 
  
  signal(SIGALRM, progress); 
  alarm(1); 
  
  len = read(0, buf, sizeof(buf)); 
  for (i = 0; i < len; i++) { 
    unsigned char c = buf[i]; 
    for (j = 0; j <= 0xff; j++) { 
      buf[i] = j; 
  
      counter++; 
      if (try_zlib(buf, len)) 
        printf("i=%d, j=%x\n", i, j); 
    } 
    buf[i] = c; 
  } 
  
  alarm(0); 
  fprintf(stderr, "\n"); 
  return 0; 
} 

編譯和運行的結(jié)果：

gcc -Wall -Werror -O3 munge.c -o munge -lz 
./munge <zlib 

有一些錯誤出現(xiàn)（如果你在zlib的信息頭中得到”no data”信息，zlib認為它運行的很好：））。但是我中途得到了下面的信息：

i=5642, j=c7 

等到運行完結(jié)束，末尾獲得了更多的記錄（整理crc文件匹配了我們損壞的文件）。有一個很好的機會，在中間的記錄，就是源代碼的問題

在一個十六進制編輯器中對字節(jié)稍微做了一些調(diào)整，zlib解壓縮（毫無錯誤?。缓蠊艿垒敵?rdquo;git hash-object”,報告了損壞文件的shal值，成功了！

我修正packfile文件本身：

chmod +w $pack 
printf '\xc7' | dd of=$pack bs=1 seek=51659518 conv=notrunc 
chmod -w $pack 

發(fā)現(xiàn)’\xc7′來自與替換我們的“munge”程序。把原來的對象偏移（51653873）導(dǎo)出了偏移量51659518 。通過“munge”（5642）增加了代替部分的偏移量，然后增加了之前去掉的3字節(jié)的git信息頭。

最后，”git fsck” 清理干凈。

關(guān)于沖突本身來說，我很幸運它確實是一個字節(jié)。實際上，證明就是單獨的位。0xc7字節(jié)發(fā)生沖突成為0xc5.所以推測由錯誤的硬件引起，或者物理射線。

緊接著，中止關(guān)注于解壓縮的輸出是錯的嗎？我本會一直看前面的部分這樣永遠不會發(fā)現(xiàn)它。下面是解壓縮后沖突數(shù)據(jù)的不同，真正的數(shù)據(jù)文件：

-       cp = strtok (arg, "+"); 
+       cp = strtok (arg, "."); 

調(diào)整了一個字節(jié)，最終仍然是有效的，可讀的C碰巧做了完全不同的事情！一次不同嘗試會造成幸運的日子，看看zlib的輸出可能確實有用，正如大多數(shù)隨機的改變也許就會破壞C代碼。

但更重要的是，git的hash、檢驗和引起了在另外一個系統(tǒng)中，很容易不被檢測問題。這個結(jié)果仍然會編譯，但是可能就引起一個有趣的bug（歸咎于一些隨機性的提交）

原文鏈接：http://thread.gmane.org/gmane.comp.version-control.git/236238

譯文鏈接：http://blog.jobbole.com/50108/