如何确保在调用File.Delete("XXX")之前对XXX的写入操作已经结束

[Alpha0Roc]

今天尝试写了一个文件粉碎的小程序。先用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进制操作文件编辑器打开，证明文件确实能够被填充。
　　不知这个问题该如何解决。

[Alpha0Roc]

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

[zhy0101]

怎么会没写完就执行呢。一个正在写的文件不能删的。

[zhy0101]

还有，你确保这样写0写1之后就不能回复了吗？我声明，我不懂这个。