仅仅是期末考试之后的娱乐节目而已，我们都知道软盘和FAT文件系统已经淘汰N个世纪了。

首先，想必如今没有人家中还在使用软盘，大部分电脑也已经不再附带软驱了，我的本本就是。所以这里的软盘是虚拟出来的。

[bachue@localhost ~]$ dd if=/dev/zero of=floppy.img bs=1024 count=1440
1440+0 records in
1440+0 records out
1474560 bytes (1.5 MB) copied, 0.0217136 s, 67.9 MB/s
[bachue@localhost ~]$ mkfs.vfat floppy.img
mkfs.vfat 3.0.9 (31 Jan 2010)

用dd创建一个1440×1024字节，即1.44MB的虚拟磁盘，按照vfat文件系统进行格式化，就可以模拟出软盘了。

然后使用虚拟机，这里使用的是VMware Player，具有挂载虚拟软盘的功能，据我所知，另一个带有此功能的是微软的虚拟机VPC，而开源界用的较多的VirtualBox，我没有找到这个功能。

在虚拟机中挂载软盘。毫无疑问，使用Linux自己的挂载功能是完全可以的，但是使用Windows，更有实战的味道。（搞笑，谁这年头还会拿个软盘来让你恢复？）

挂载成功。

随便写点神马吧。。表太和谐就行。

文件写入完毕

假设现在出现误操作，删了文件

表痛哭流涕，回Linux修复去。

用vim打开虚拟软盘文件。（如果是真的软盘，用dd命令拷贝整个软盘进来，成功之后可以用同样的方法拷回去）

打开只有会发现虚拟软盘文件难以阅读，因为其实是二进制的，用:!xxd进入vim的十六位编辑模式。

这样差不多能读了。

表以为文件被删除后永远找不到，其实FAT文件系统仅仅修改了FAT表和FDT表而已，文件真正的内容其实根本没有被擦除，而是等待将来被覆盖，这就是我们为什么能恢复的原因。或是说艳照门为什么会发生的原因。

查看虚拟软盘文件的内容就可以发现，事实上文件的全部内容都存储在0x4200位置，这是软盘数据区的起始位置，共占用512字节，即0x4200~0x4400，文件没有超过512字节，因此没有用到的部分被浪费。学过FAT文件系统的都知道，既然文件内容在0x4200，那么它的位置就是软盘的第三簇，其实相当于Linux文件系统的第一个逻辑块。通过计算可知，0x4400对应第四簇，0x4600对应第五簇，以此类推。立即定位到FAT的位置0x0200，发现当前内容是F0FF FF00 0000，按照FAT12的12位一簇的阅读方法，第一簇是FF0，第二簇是FFF，这两簇为文件系统自身拥有，不要乱动。存放要恢复的文件的第三簇现在是000，证明文件已经被删除。我们必须恢复或是说猜测删除前的第三簇的内容。由于文件不超过512字节，仅用一簇即可存储，因此，毫无疑问内容应该是FFF，立即修改，修改后的结果如图所示，注意用vim的替换而不是插入，否则会造成虚拟软盘的大小不再是严格的1.44MB，不是1.44MB的软盘送进VMware，能不能被读取就不知道了。FAT文件系统的FAT表共有两张，内容一致，冗余存储，因此我们必须修改位于0x1400的第二张FAT表。

修改成和第一张FAT表完全一致。

接下来处理FDT表，之所以和FDT有关是因为被删除的文件在根目录下，Windows的文件系统和Linux不一样，根目录的目录项归FDT管。

查看FDT的内容我们可以发现，其实被删除的文件仅仅是文件名的第一个字节被改成了0xe5而已，没有更多改动了，之前文件名是file.txt，因此这里的文件名应该是FILE，F的ASCII码是0x46，修改成如图所示即可。

至此，修复已经完成，该保存退出vim了。但是这里有个注意事项，如果现在就用:wq保存退出，那么别说之前的修复工作，整个虚拟软盘文件将全部损坏，前功尽弃，我至今也不知道如何挽回。这是因为当前是十六位编辑模式，必须先退回普通的编辑模式才行。

方法如图所示，使用:%!xxd -r，切回那种没办法看的普通的编辑模式，然后再用:wq保存退出。

hexdump -C floppy.img

用hexdump -C命令阅读虚拟软盘文件，检查修改结果。

hexdump将全是0的行隐藏起来，使得1.44MB大小的文件的有效内容全部展现出来。留意一下文件大小，必须是严格的1.44MB。

重新在虚拟机中挂载这个虚拟软盘，看见文件和内容都已经成功恢复，游戏胜利。

类似的方法不能用在其他文件系统上，FAT之所以能这么做，只是因为自身结构简单，而且恢复非常容易，因此也被淘汰了。现代文件系统要恢复可没有这么简单。