我有一个 md5sum 列表和很多我想校验和然后根据 md5sum 列表重命名它们的文件。
列表示例:
d4cd401ade018617629b39efed7b7be4 foo.bar
8fdb07ca55c164e0d5a69eff49fe800e bar.foo
8b167d01009f066aaf2d6c1ba336d842 foobar
Run Code Online (Sandbox Code Playgroud)
现在我想对当前目录中的每个文件进行校验和,如果校验和与上面的列表匹配,则将其重命名为正确的列。
我怎么能做到这一点?
我已经在 ZFS 上成功设置了 Debian 伸展,包括根文件系统。事情按预期进行,我认为我已经理解了基本概念 - 直到我重新阅读了 Sun 的 ZFS 文档。
我的场景是:
我想防止(更准确地说:检测)无声位腐烂
目前,我已经设置了一个带有一个 vdev 的根池,它是两个相同磁盘的镜像
当然,我确实打开(即没有关闭)校验和
现在我遇到了这个文件。在页面的末尾,他们显示了zpool status示例配置的命令输出,
[...]
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
c1t0d0 ONLINE 0 0 0
c1t1d0 OFFLINE 0 0 0 48K resilvered
[...]
Run Code Online (Sandbox Code Playgroud)
接着是声明:
READ 和 WRITE 列提供设备上发生的 I/O 错误的计数,而 CKSUM 列提供设备上发生的不可纠正的校验和错误的计数。
首先,在这种情况下,“设备”是什么意思?他们是在谈论物理设备、vdev 还是其他东西?我的假设是他们正在谈论层次结构中的每个“设备”。vdev 错误计数器可能是其物理设备的错误计数器的总和,而池错误计数器可能是其 vdev 的错误计数器的总和。这样对吗?
其次,不可纠正的校验和错误是什么意思?这是一个我认为在谈论物理磁盘时通常使用的术语,无论是与从盘片到磁盘电子设备的数据传输有关,还是与磁盘上物理扇区的校验和或从磁盘端口(SATA、SAS、 ...)到主板(或控制器)。
但我真正感兴趣的是 ZFS 级别(而不是硬件级别)是否存在校验和错误。我目前确信 CKSUM 正在展示后者(否则,它没有多大意义),但我想确定。
第三,假设他们谈论的校验和错误确实是ZFS级别(而不是硬件级别)的校验和错误,为什么他们只显示不可纠正错误的数量?这没有任何意义。我们希望看到每个校验和错误,无论是否可以纠正,不是吗?毕竟,校验和错误意味着磁盘上存在某种硬件未检测到的数据损坏,因此我们可能希望在出现 …
有一个gz格式的40GB文件。我想查找cksum未压缩格式的该文件的记录数。我的一种方法是:
gunzipwc,命令cksumgzip。这种方法的问题是提取和压缩文件将花费大量时间。可能需要 30-40 分钟左右。另一种方法可能是用来zcat计算记录数和cksum
zcat <file name> | wc -lzcat <file name> | cksum这种方法可能需要更少的时间,但zcat对同一个文件使用两次。有更好的方法吗?可能正在使用一个命令来查找记录计数和cksum?
我想将校验和信息嵌入到我传输的文件中。它是tar.gz或tar.xz文件,我只能将一个文件传输到远程端。
您如何建议我嵌入校验和信息?
我想要整个档案的校验和,而不是它的内容(我想在“解包之前”检查它的完整性)。
我知道我可以以某种支持校验和的格式(如rar)重新打包它,但是“重新打包”东西的计算成本,只是为了添加校验和(另一方面我不喜欢rar格式)。所以首选是gzip& gunzipetc 之类的东西,但用于添加、检查和删除校验和。
任何工具、想法、脚本、解决方法?
我是对的.xz并.gz支持串联吗?也许值得使用此功能在文件末尾附加压缩校验和?
# Create random file
$ dd if=/dev/urandom /of=./test.dat bs=1K count=1
# Zip it
$ zip test.zip test.dat
# Dump contents for ZIP-computed CRC
$ unzip -v test.zip
Archive: test.zip
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
1024 Stored 1024 0% 2018-12-09 17:42 1f197320 test.dat
-------- ------- --- -------
1024 1024 0% 1 file
# compute CRC with coreutil's cksum
$ cksum test.dat
283837118 1024 test.dat
# convert to hex
$ printf …Run Code Online (Sandbox Code Playgroud) 我从 [Sources] 那里知道,FLAC 计算 CRC 和 MD5。
恐怕flac --test只能进行 CRC 测试 - 如man flac: 中所述same as -d except no decoded file is written。
如何使用放置在给定 .flac 文件中的 STREAMINFO 中的原始 PCM 的 MD5 检查 flac 文件的正确性?
如果flac --test工作,是否有任何可靠的(如flac文档中)参考资料显示它?
资料来源:
http://en.wikipedia.org/wiki/Free_Lossless_Audio_Codec我们可以找到:
FLAC 在流协议中使用时使用 CRC 校验和来识别损坏的帧,并且还在其 STREAMINFO 元数据标头中存储了原始 PCM 音频的完整 MD5 哈希。
http://flac.sourceforge.net/comparison.html
默认情况下,在处理文件时,flac 在编码和解码时计算 MD5 总和。
要在 STEAMINFO 中查看 md5sum,我们可以使用:
$ metaflac --show-md5sum *.flac
Run Code Online (Sandbox Code Playgroud) 因此,我想对我的 Debian 9.0 安装 DVD 进行校验,以便能够将其与相应 .iso 文件的哈希值和已发布的哈希值进行比较,从而能够验证我的安装的完整性。
我在 Ubuntu 下将 Debian 安装 .iso 刻录到 DVD 上。验证 DVD 校验和时遇到问题,因为它在 50% 左右时不再继续,剩余时间只会不断增加。然而,这可能是由于我在刻录或校验和期间不小心在 .iso 文件上执行了 sha512 (它有错误并且似乎没有修改 .iso)而不是 sha512sum。(.iso 的 sha512 哈希值是正确的。)
我想使用 sha512,似乎我首先需要 DVD 的块大小(以字节为单位)。
这两个问题对我有帮助,但不能解决这个问题:
编辑:相关问题/我的发现
我正在寻找一种简单的解决方案来防止存储在各种驱动器上的数据发生随机位翻转(所谓的位腐烂)。它们不是磁盘阵列,只是单个磁盘,我每周备份一次。所以我不是在寻找冗余,而是为了文件完整性——即我想知道我很长时间没有访问过的文件是否被随机损坏,并希望在可能的情况下修复它们。
请注意,我想要一个通用的解决方案,我并不是在寻找像 ZFS 或 btrfs(我已经知道)之类的文件系统,部分原因是它们仅用于校验和的开销太大,而且它们太复杂了/ 不稳定(btrfs 情况)。
它不一定是自动的。也就是说,如果我必须运行一个命令来为新写入的文件生成校验和(可能还有恢复),那很好,但它应该易于使用,而不是像手动存储校验和并验证然后将坏文件复制回来等(我已经在做,这就是为什么我要求更简单,更少手动的东西)。
乍一看,SnapRAID似乎做我想做的,除了它是为磁盘阵列制作的,这是我的问题。我认为它可以只使用 1 个数据磁盘和 1 个奇偶校验磁盘,在这种情况下,奇偶校验磁盘可能是数据磁盘的镜像(备份),但我不确定。
除此之外,它可以满足我的需求:校验和文件,验证这一点的能力,甚至可以从备份(奇偶校验)中修复它们。我仍然会在外部媒体上每周运行一次备份,但是这个本地备份需要更少的手动操作,因为它开始变得难以管理。
是否还有其他工具,例如SnapRAID仅针对 1 个数据磁盘或文件系统而设计的工具,它们通过自动校验和/备份进行保护,还是我应该使用SnapRAID?只有 1 个磁盘可以正常工作吗?
因为它使用奇偶校验磁盘进行备份,所以在使用它之前我必须完全擦除我的本地备份磁盘SnapRAID,所以我犹豫是否只是为自己“测试”而无需确认。这样做的一个缺点是奇偶校验磁盘不能作为普通磁盘访问,即使在这种情况下它不是真正的奇偶校验磁盘而只是一个镜像。
因此,如果有另一个类似的易于使用的工具来处理1 个磁盘而不是磁盘阵列的文件的备份和完整性,我想知道。谢谢。
假设我输入并运行以下命令:
sha256sum ubuntu-18.04.1-desktop-amd64.iso
Run Code Online (Sandbox Code Playgroud)
延迟后,这将输出以下内容:
5748706937539418ee5707bd538c4f5eabae485d17aa49fb13ce2c9b70532433 ubuntu-18.04.1-desktop-amd64.iso
Run Code Online (Sandbox Code Playgroud)
然后,我意识到我应该输入以下命令来更快地评估 SHA?256 哈希是否匹配:
sha256sum ubuntu-18.04.1-desktop-amd64.iso | grep 5748706937539418ee5707bd538c4f5eabae485d17aa49fb13ce2c9b70532433
Run Code Online (Sandbox Code Playgroud)
有没有办法在不使用sha256sum命令第二次验证校验和的情况下对第一个输出采取行动(即避免这样做造成的延迟)?具体来说:
grep在双引号粘贴校验和(即,作为字符串)上使用是行不通的。)我曾经crc32将一些文件与它们的备份进行比较。在 3556 个文件中,有 11 个被报告为“BAD”,如下例所示:
9be46354 ./9836Feeding_the_dog_.mpeg BAD 9be46354 != 9836Feed
Run Code Online (Sandbox Code Playgroud)
然而,这些文件并不错,但由于某种原因crc32将其计算的校验和与部分文件名进行了比较。
然后我尝试了一个实验:
$ echo 12345 > 9836Feeding_the_dog_.mpeg
$ crc32 9836Feeding_the_dog_.mpeg
261dafe6
Run Code Online (Sandbox Code Playgroud)
所以这次crc32似乎没有将校验和与文件名进行比较,并且该文件不是“BAD”。
这里发生了什么?其他校验和也会发生这种情况吗?