【python】CRC32(C)多线程文件校验工具_v1.21

【更新日志】


2025-03-31（V1.21，网盘资源链接不变）：
合并progress_printer和progress_cleaner两个线程（函数）到progress_manager线程，
并根据观察，仅需一次部分遍历经过copy的progress_dict，就能达到原先的效果，少了个线程、减少了for循环的时间，在理论上提升了性能。

原先，因为程序运行时，最多只有4个在跑文件读写以及访问储存进度的公共资源（全局变量），由于每个文件的读写速度差异，所以同时走到同一步、写入同一个全局变量造成竞争的可能性微乎其微，所以就把线程锁忽略了。
现在为了保险起见，对file_error、file_corrupted、file_passed和possible_moved_file_dict这4个全局变量各自加了对应的线程（互斥）锁保护。

现在的校验程序（校验CRC32C.py/exe）增加了支持识别文件移动、文件多余的情况。原先V1.2只能识别文件被修改、文件丢失（有可能只是被移动，但原来识别不出来）的情况。






这是一款由我用python编写，通过在分享前获取文件CRC32C校验值并记录在文件中，和在接受文件之后根据记录文件比对文件CRC32C的方式，方便文件分享者和接收者确认数据完整性、正确性的工具。


本人在吾爱破解论坛上也发过这个软件的帖子：
https://www.52pojie.cn/thread-1925899-1-1.html
https://www.52pojie.cn/thread-1995465-1-1.html




因为希望有压制组能用上的我的软件，所以到这个论坛来再发一遍（这一点我就直说了）。




如果管理员看完觉得有用的话，帮忙置顶一下，哪怕一两周就行，谢谢。






软件的“卖点”是：速度快！快！总之就是快！


速度潜力可以到15～20GiB每秒（同样采用1GiB大小的随机内存内容测试，intel的9750H笔记本CPU），相比普通crc32软件（7-zip），理想条件下（nvme、单文件夹下有多个文件、文件大小较大），能省下一半的校验时间。
未来PCIE5.0硬盘的读取速度估计也差不多可以到15GiB每秒，可以“战未来”了。


下面直接粘贴软件的详细介绍和链接下载地址。


注意！！
软件为了利用CPU中SSE4.2指令集的CRC32指令提升计算效率，降低CPU占用，因此用到的python库crc32c及其使用的CRC32C标准，和常用的CRC32(B)标准相比，也就是大多数压缩软件和校验程序提供的CRC32，有很大的区别，两者不能通用，也就是不能用常规的计算CRC32的方法来校验本程序生成的CRC32C记录，所以建议无论是分享前记录CRC的过程，还是接收到文件之后的比对，都不要离开本软件。


关于crc32的CPU指令的详细介绍，参见下方这篇文章：
【基于Intel SSE4.2指令集crc32指令进行快速crc32c校验(使用Delphi/Fpc内联汇编实现)】
https://www.52pojie.cn/thread-1584310-1-1.html
(出处: 吾爱破解论坛)





软件（和源码）链接：

①百度云：（拥有完整资料，包括软件自身、操作演示视频和原老版本软件演示视频中的音乐文件分享）
https://pan.baidu.com/s/1iBlKi5hV_kdkkzCgVjblYQ?pwd=0000


②蓝奏云：（因文件大小100M限制，只有软件自身、源码和一个说明用的txt文本文件，以及导航用的、存有百度云链接的文本文件）
https://wwm.lanzouq.com/b0ny5lvuf


③没有百度云VIP账号，想要看操作演示的，
请访问下面这个链接，到B站收看：
（注意！新版的操作演示去掉了音乐欣赏，改由本人实时录音解说，
但上面的百度云链接里还存放着这些音乐文件，也新增了些音乐文件）
https://www.bilibili.com/video/BV18rupeWEt7



软件github地址：https://github.com/ssh-buanshishi/adaptive_multi-thread_crc32c_file_verify_tool






工具基于python的wmi模块获取文件路径所在磁盘的数字编号，然后基于磁盘SMART工具“smartctl.exe"（pySMART模块调用的exe程序）根据前面获取到的磁盘数字编号，获取对应磁盘的旋转速度、接口类型、是否为SSD的SMART属性，以此判断磁盘硬件类型（固态／机械），并合理分配同时读取的文件数（线程数）。

①在机械硬盘（HDD）上以单线程读取文件（逐个读取文件），降低机械盘寻道压力的同时，读取、计算校验的速度也能赶上机械盘自身的连续读取大文件的速度，这种情况下和7-zip读取校验CRC的速度不相上下；

②而在nvme和SSD上以4线程读取文件（同时读取4个文件），在获取一个文件夹下的多个文件（递归）CRC值的场景下，相较于7-zip和已有的大部分校验软件，速度上应该会有显著提升，可以加快校验速度，节省时间。在我自己电脑的nvme固态盘上测试，读取速度相较原来翻了一倍。4个线程也是我多次测试所得最优线程数。

③在不能读取识别明确硬件类型的磁盘上（U盘、虚拟磁盘……），以2线程读取文件（同时读取2个文件）；

④识别磁盘硬件类型出错的情况下，以单线程运行。







★程序兼容性良好，最低可以支持win7（32位），win7之后的版本跑起来应该没问题，至少自己的win10试过了。
★通过接收argv[1]或者双击后弹出文件夹选择框（tkinter窗口可以自适应系统缩放，应该大概率不会模糊）来接受文件夹路径。
★记录文件使用预分配方式写出，极大概率保证了不会出现文件碎片。






软件截图：

弹出的文件夹询问窗口

win10运行界面

win7运行界面

至于对更快的读取速度的追求，我已经尝试过pywin32库的win32file模块的CreateFile函数（带【FILE_FLAG_SEQUENTIAL_SCAN】的flag）和ReadFile函数，相当于直接调用windows的文件api，结果相比较python自带的f=open(xxx,mode="rb")和f.read()，提升基本察觉不到。
mmap模块创建memory mapped file也试过，结果速度太垃圾了，自己的nvme固态上的多线程一共只有500～600MiB/s的读取速度（原本可以达到2 GiB/s左右）。

CRC32的计算速度现阶段基本上是受制于硬盘的速度的，我之前写CRC32C校验软件的时候用python测试过，用内存中的随机数据来跑，常见的CRC32（B）的软件算法的速度，能达到5-6GiB每秒。这款CRC32(C)多线程文件校验工具所用到的python库crc32c：
https://pypi.org/project/crc32c/ ， https://github.com/ICRAR/crc32c） ，
因为可以调用CPU的SSE4.2指令集中的crc32指令，所以速度更快，可以到15～20GiB每秒（同样采用固定大小的随机内存内容测试），现阶段应该很难找到比这个校验速度更快的校验算法了，MD5和SHA算法我记得也才大概700～900MiB每秒。
SSE4.2指令集现在也普及了，AMD的锐龙，intel七代以上的估计都有。

未来PCIE5.0硬盘的读取速度估计也差不多可以到15GiB每秒，可以说这个crc32c的硬件加速指令算法是可以“战未来”的。


对于这个crc32c的库，说起来我自己也稍微贡献了一部分意见和建议：https://github.com/ICRAR/crc32c/issues/51，这个issue的对话中，头像和52pojie这边一样的就是我。
现在想来，还得谢谢当初的自己，在python3.8维护周期结束前提交了issue，才有了现在已经比较完善的crc32c的2.7.1版本（可以一直用下去的那种），不然未来这个库的作者是否放弃对python_3.8的支持就很不确定了。

我观察过，番剧压制组【Moozzi2】在每次发布的种子的文件夹里都有类似【checksum.md5】的校验文件，说明现在校验文件的工具还是“有市场”的。
虽然sha、md5的安全性比crc32（包括crc32c之内的一系列crc算法）更高，但是crc32c硬件加速指令算法的速度，目前可以说很难找到更快的了。在日常下载影片、番剧、图片的应用场景下，尤其是这种文件比较大的情况下，几乎不会有人有闲工夫逆向破解crc32算法，我们更关心下载的文件是否完整。

所以相信未来crc32c文件校验工具肯定有自己的一席之地。
我也希望这个软件自身或者软件代码，在未来能被更多人用到。

PS：我已经不止一次幻想过番剧压制组用上我的crc32c校验工具的场景了。
如果哪位大佬有番剧组的渠道、联系方式，记得向他们推荐推荐这款软件，不求完全替换原来的校验方法，只要多上一个我的软件生成的校验记录就行（但愿未来能实现吧～）

大佬牛呀，支持一下。下软件送音乐，本体是音乐麽！我感觉都挺好听的，没鉴赏完还舍不得移除。

支持原创

我靠！大佬牛逼！

支持一波（虽然上网冲浪至今从未使用过任何文件校验工具www）

这真的是牛呀，支持了

OOpWer 发表于 2024-12-29 20:11
大佬牛呀，支持一下。下软件送音乐，本体是音乐麽！我感觉都挺好听的，没鉴赏完还舍不得移除。

用的解析工具吗？还有两个文件夹别漏掉哦

GitHub star了。
不过如果不和其他程序兼容还是比较难受的。。。