2012-02-09 4 views
0

Я пытаюсь создать файл проверки с помощью автоматического обновления для моей программы.проверка файла с автоматическим обновлением

Идея состоит в том, что пользователь просто загружает пусковую установку для моей программы и что пусковая установка загрузит все необходимые файлы по нескольким настройкам, указанным местным пользователем. и что он также будет проверять, есть ли файлы: 1) Up-to-Date, 2) Corrupt, 3) Не найдено, 4) Требуется обновление. 2,3,4 приведет к тому, что файловый контролер добавит файл в список To_Download, а если он равен 1, проверка файла отметит его как действительную и продолжит.

Для этого я подумал написать функцию контрольной суммы, проверить все файлы и сравнить хэши с известными здоровыми хэшами (я использую неуправляемый SHA1). Однако, если я потом загружаю новый экземпляр этого файла с сервера, контрольная сумма заканчивается совсем по-другому, хотя я знаю, что файлы полностью идентичны, за исключением другого мода/времени создания.

Мне нужна надежная проверка файлов, которая быстрая, но непростая для обхода. Помимо того, что я уверен, что файлы на компьютере пользователя совпадают с файлами на сервере.

Причина, по которой я использую Sha1, заключается в том, что я читаю, что она имеет меньше «столкновений», а столкновение более «дорого» для создания по сравнению с альтернативой md5.

В настоящее время с помощью

using (FileStream fs = new FileStream(FilePath, FileMode.Open, FileAccess.Read)) 
using (BinaryReader file = new BinaryReader(fs)) 
{ 
    SHA1CryptoServiceProvider unmanaged = new SHA1CryptoServiceProvider(); 
    byte[] retVal = unmanaged.ComputeHash(file.ReadBytes(Convert.ToInt32(fs.Length))); 
    file.Close(); 

    StringBuilder stringBuilder = new StringBuilder(); 
    if (retVal != null) 
    { 
     foreach (byte b in retVal) 
     { 
      stringBuilder.Append(HexStringTable[b]); 
     } 
    } 
} 

и hexstringtable

private static readonly string[] HexStringTable = new string[] 
    { 
     "00", "01", "02", "03", "04", "05", "06", "07", "08", "09", "0A", "0B", "0C", "0D", "0E", "0F", 
     "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "1A", "1B", "1C", "1D", "1E", "1F", 
     "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "2A", "2B", "2C", "2D", "2E", "2F", 
     "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "3A", "3B", "3C", "3D", "3E", "3F", 
     "40", "41", "42", "43", "44", "45", "46", "47", "48", "49", "4A", "4B", "4C", "4D", "4E", "4F", 
     "50", "51", "52", "53", "54", "55", "56", "57", "58", "59", "5A", "5B", "5C", "5D", "5E", "5F", 
     "60", "61", "62", "63", "64", "65", "66", "67", "68", "69", "6A", "6B", "6C", "6D", "6E", "6F", 
     "70", "71", "72", "73", "74", "75", "76", "77", "78", "79", "7A", "7B", "7C", "7D", "7E", "7F", 
     "80", "81", "82", "83", "84", "85", "86", "87", "88", "89", "8A", "8B", "8C", "8D", "8E", "8F", 
     "90", "91", "92", "93", "94", "95", "96", "97", "98", "99", "9A", "9B", "9C", "9D", "9E", "9F", 
     "A0", "A1", "A2", "A3", "A4", "A5", "A6", "A7", "A8", "A9", "AA", "AB", "AC", "AD", "AE", "AF", 
     "B0", "B1", "B2", "B3", "B4", "B5", "B6", "B7", "B8", "B9", "BA", "BB", "BC", "BD", "BE", "BF", 
     "C0", "C1", "C2", "C3", "C4", "C5", "C6", "C7", "C8", "C9", "CA", "CB", "CC", "CD", "CE", "CF", 
     "D0", "D1", "D2", "D3", "D4", "D5", "D6", "D7", "D8", "D9", "DA", "DB", "DC", "DD", "DE", "DF", 
     "E0", "E1", "E2", "E3", "E4", "E5", "E6", "E7", "E8", "E9", "EA", "EB", "EC", "ED", "EE", "EF", 
     "F0", "F1", "F2", "F3", "F4", "F5", "F6", "F7", "F8", "F9", "FA", "FB", "FC", "FD", "FE", "FF" 
    }; 

Любые идеи, почему файл, который загрузить свежие имеет другой хэш, чем ожидалось (как это идентично?)

редактировать

Я чувствую себя глупо, потому что не сравниваю 2 файла в шестнадцатеричном коде. Кажется, проблема в том, что в этих файлах был 1 отсутствующий байт, я исправил эту проблему сейчас. в настоящее время требуется 60-70 секунд для проверки всех 7000 файлов, есть ли возможность ускорить это?

+0

Вы, скорее всего, IO связаны в данный момент - единственный способ ускорить бы для создания хэшей только над определенными частями входного файла, которые снова не гарантируют поиска изменений. Помимо этого вы можете избавиться от 'StringBuilder' и просто сравнить байты напрямую. – BrokenGlass

ответ

1

Вы пытались сравнить файлы, чтобы посмотреть, что изменилось? Если SHA1 отличается, файлы разные (modtime не имеет к этому никакого отношения.) Попробуйте различить их или сравнить их в шестнадцатеричном редакторе, чтобы увидеть, что другое.

+0

Я сделал это, и кажется, что по какой-то причине файл имеет 1 отсутствующий байт. Я это исправил. – Raskaroth

1

Ваша логика кажется правильной и приведет к строкам хэш-кодов, которые должны совпадать для идентичных файлов. Однако вы можете сделать это гораздо короче и без необходимости справочной таблицы (или оставить эту часть в только из соображений производительности):

public string CreateFileHash(string filePath) 
{ 
    using (FileStream fs = new FileStream(filePath, FileMode.Open, FileAccess.Read)) 
    { 
     SHA1CryptoServiceProvider unmanaged = new SHA1CryptoServiceProvider(); 
     byte[] retVal = unmanaged.ComputeHash(fs); 
     return string.Join("", retVal.Select(x=> x.ToString("x2"))); 
    } 
} 
+0

Только причина, по которой я использую таблицу поиска по соображениям производительности – Raskaroth

+0

Ваш оригинальный алгоритм работал на пару тестовых файлов для меня - вы уверены, что загрузка завершена, когда вы ее запускаете? – BrokenGlass

+0

по какой-то причине загрузчик не записывал последний байт в каждом файле. Я решил эту проблему. Какова эффективность алгоритма? – Raskaroth

Смежные вопросы