今天尝试写了一个文件粉碎的小程序。先用0对文件填充,再用1对文件填充,最后删除此文件。但是在具体操作的时候遇到一些问题——程序执行结束后,用FinalData等恢复软件将被删除文件恢复出来,结果发现很多文件都是在没有被填充完整的情况下就删掉了。特别一些1K左右的文件,更是未被填充就直接删除了;容量大些的文件略好点,文件大部分已填充。但即使是那些被填充一部分的文件,似乎填充也有问题,在0未填充完成的情况下就已经开始填充1了。
  这似乎显示,程序在执行时,对文件写入未结束,就已经调用File.Delete()将文件删除了,而且文件的写入也不是顺序执行的。
FileStream fS = new FileStream(Path.Combine(filePath, fileName),
FileMode.Open, FileAccess.Write, FileShare.None);
while (fS.Position < fS.Length)
{
fS.WriteByte(0xFF);
}
fS.Flush();
fS.Close();
File.Delete(Path.Combine(filePath, fileName));
  后来注释了最后一句File.Delete(),再次执行,并用支持16进制操作文件编辑器打开,证明文件确实能够被填充。
  不知这个问题该如何解决。

解决方案 »

  1.   

    在一篇文章上看到的(http://blog.joycode.com/moslem/archive/2005/10/11/64923.aspx),是文件删除标准的简化方式。大概原理就是在删除文件前把文件内容进行覆盖,再删除。确实,这么做的话,如果成功,用FinalData等程序再恢复,文件原始数据就已经没有了。
    另外,写文件时文件确实不应该被删除。但是一个奇怪的问题是,如果我运行注释了Delete()的程序,接着手动删除此文件,那么用FinalData等程序打开,文件内容显示都是填充了“0xFF”的。但如果不注释Delete(),那被删除文件的内容就大概分3部分,文件开头部分全是"0xFF"(第二次填充的内容),中间部分"0x00"(第一次填充的内容),文件结尾部分一般是文件原始内容。