分类
综合技术

记一次机械硬盘出现数据写入错误的真实案例

(在苹果系统下,如果文章中的图片不能正常显示,请升级Safari浏览器到最新版本,或者使用Chrome、Firefox浏览器打开。)

由于博主做的工作原因,最近获取到了一批语音数据集,全部为wav格式。数据拿到手,自然要将数据存储到自己的硬盘中。由于固态硬盘的容量有限,所以我就将其全部复制粘贴到机械结构的移动硬盘中,随后要进行的工作就是数据的处理。

但是在进行数据的处理和程序debug的时候,会出现程序在处理到某些数据的时候,突然抛出异常并崩溃的异常,直觉告诉我是数据出了问题,于是我在程序中对异常进行了捕获,定位到了是在处理哪一条数据时出现了异常,以及异常的原因。

根据出现错误的以0开头计数的数据序号,在数据目录列表中找到了对应的文件名和文件路径。

于是,我很好奇这个wav文件为什么不是以“RIFF”开头的。首先,通过16进制查看器查看这个文件的16进制的存储内容。

果然,这个文件不是以“RIFF”开头的,也就是说,文件头标记根本不是wav文件的头部标记,那么,出现那个异常也就在情理之中。另外,我们甚至可以在对应的ascii编码的内容中,看到拍照设备之类的信息。但是,好好的wav文件,怎么可能就没有RIFF标记了呢?

为了解释这个问题,我继续观察这个16进制存储的信息内容,可以看到,在0x06到0x09位置这四个字节,是jpg图片格式的文件头的一个标记。那么,意思就是说,我拿到的wav文件是个假的wav文件,其实就是个图片?于是,带着好奇心,我将文件的扩展名改为.tiff试试,果然,一个可见的图片在缩略图中显示了出来。

看到这张图片,我马上想起来,这不是我之前在某个房间内对着白板拍的照片吗?为了验证,我最后确实在我的硬盘中找到了这张图片。但是,为什么这张照片会混入到wav数据集中去呢?阴谋论浮现在我的脑海,难道数据提供方窃取了我硬盘中的文件,不小心混入wav数据集中让我发现了?

为了解决这个疑惑,我找到了原始数据直接备份后的压缩文件包,找到了同样文件名,但后缀为jpg的文件,使用16进制查看器进行查看。

唉?原始文件是没有问题、完好无损的。那么,这个阴谋论就不攻自破了,这张混入的假wav真jpg的文件就不可能是被窃取的,所以,问题只能出现在文件的复制上。

检查了一下临近的几十个wav文件,都出现了这种类似的问题,但是内容不可理解,不像这个文件一样可以找到明显的标识。连续的若干文件都出现了这类问题,就更加印证了这一点。通过查看复制后文件的修改时间,为某一天的下午4点多,也就是白天。而前后没有问题的文件在修改时间上,也都是有先后顺序的,那么也排除了后来发生文件修改的可能,只能是复制的时候,就出现了问题。

通过查找资料了解到,一般来说,机械硬盘中,文件的读写操作会导致机械硬盘处于脆弱状态,尤其是写操作,时间成本很高,写入的速度慢,延时大,一般都是以毫秒来计的。当机械硬盘有读写操作时,任何干扰,尤其是震动,都会对硬盘的机械结构和物理状态产生影响,当影响超出抗干扰的阈值时,硬盘的读写错误便产生了。震动等干扰,在严重时,甚至会直接损坏硬盘。

由于机械硬盘的结构特性,我们使用的时候,在硬盘通电之前,一定要将硬盘或者笔记本电脑放平稳,在使用中不要晃动,开着机背着电脑跑来跑去,或者用手去摆弄通电的移动硬盘,也不是一个好习惯。只有在硬盘断电之后,机械运动全部停止,硬盘才会处于安全状态,这时候我们拿着它到处跑,就没有什么问题了。硬盘有价,数据无价,为了数据的安全,养成一个好的使用习惯,对于当今离不开信息化社会的我们来说很重要。

版权声明
本博客的文章除特别说明外均为原创,本人版权所有。欢迎转载,转载请注明作者及来源链接,谢谢。
本文地址: https://blog.ailemon.net/2019/04/20/remember-real-case-of-data-write-error-in-mechanical-hard-disk/
All articles are under Attribution-NonCommercial-ShareAlike 4.0

关注“AI柠檬博客”微信公众号,及时获取你最需要的干货。


发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注

18 − 1 =

如果您是第一次在本站发布评论,内容将在博主审核后显示,请耐心等待