文件检查与自动更新
我想创建一个文件检查器与我的程序的自动更新程序。文件检查与自动更新
这个想法是,用户只是为我的程序下载启动程序,然后启动程序将下载本地用户指定的几个设置所有必需的文件。并且它还将检查文件是否为: 1)最新版本, 2)损坏, 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"
};
任何想法,这是为什么下载新的文件有不同的哈希比预期的(因为它是相同的?)
编辑
我觉得愚蠢的做法是不比较一个hexeditor中的两个文件。看起来问题是这些文件中有一个丢失的字节,现在我已经解决了这个问题。目前需要60-70秒才能检查所有7000个文件,有没有可能进一步提高速度?
您是否尝试过比较这些文件以查看发生了什么变化?如果SHA1不同,则文件是不同的(modtime与此无关)。尝试对它们进行比较或在十六进制编辑器中比较它们以查看不同之处。
我这样做了,似乎由于某种原因该文件有1个丢失的字节。我现在解决了。 – Raskaroth 2012-02-09 19:14:00
您的逻辑似乎是正确的,并且会产生应匹配相同文件的哈希码字符串。然而,你可以做到这一点更短,无需查找表(或保留那部分只有性能原因):
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")));
}
}
我使用查找表的唯一原因是性能方面的原因 – Raskaroth 2012-02-09 19:13:13
您的原始算法适用于我的几个测试文件 - 您确定下载在您运行时已完成吗?由于某种原因,下载器没有在每个文件中写入最后一个字节,因此请致电 – BrokenGlass 2012-02-09 19:16:33
。我已经解决了这个问题。算法的性能如何? – Raskaroth 2012-02-09 19:18:12
你是最有可能的IO在这一点上的约束 - 只有这样,才能加快会仅在输入文件的某些部分创建散列,而这又不能保证找到更改。除此之外,您可以摆脱'StringBuilder'并直接比较字节。 – BrokenGlass 2012-02-09 19:21:58