文件防写坏的一些看法

文件过滤加密不可避免的会产生一些坏文件，写坏文件有时候不是因为自身处理逻辑的问题 而是可能在处理某些写入内容的瞬间 掉电之类的。
如何避免外因 或者内因引起的 坏文件的产生应该是必须考虑的事情。
不知道 这个议题值不值的讨论 能不能讨论 呵呵
我先说两个关于如何避免坏文件 。我的想法。
1写前备份，这是最简单的事情了，在写的时候 备份 可以保证不会损失全部文件内容。至少可以恢复到修改前的部分。弱点就是效率会很低下。对于经常操作的文件 增加备份间隔 记录上次记录时间。
2 针对大文件，在磁盘上生成文件镜像，将某些写操作映射到磁盘别的位置，做成类似于还原系统的东西。并在空闲时刻进行文档整理。

浅显的想法，欢迎大家互相讨论。呵呵

驱动过多的操作文件和生成新文件会被某些杀毒软件误认为病毒，不利于兼容。

你这2个方法也没用，写前备份，如果多次保存操作，某次坏了，照样全坏；镜像也是一样；而且这些方法只会让系统变的很慢，最终客户也无法接受

如果代码本身都会导致文件出问题，那么你做再多的补救措施也没用


所以：必须保证你自己的代码不出问题，把逻辑吃透，不要奢望可以补救

这个工作是漫长的，在自己一台电脑前折腾几个月就指望能出产品是不可能的，这里很多人都磨了好几年了，需要极大的耐性啊

没有终极方式。

如果一定要找方法，参考数据库使用的方法，那是目前来说相对比较好的。但是至于实现....

现在还不急着考虑这样的问题，
“驱动过多的操作文件和生成新文件会被某些杀毒软件误认为病毒，不利于兼容。 ”这点应该不是问题。
“必须保证你自己的代码不出问题，把逻辑吃透，不要奢望可以补救”即便逻辑吃透写的再好，理论上也是可能会产生坏文件的。
“如果代码本身都会导致文件出问题，那么你做再多的补救措施也没用”这点很是同意。

“如果一定要找方法，参考数据库使用的方法，那是目前来说相对比较好的。但是至于实现....” 关于这个问题 我也想到过设计为可以“回滚”之类的，但是从效率上看 好像有点得不偿失。

我想现在的关键可能是 代价和利益的取舍，其实可能和looksail说的 代码逻辑处理好 必须保证自己代码不出问题 。当这点达到以后产生坏文件的可能已经基本等同于 或者说略大于 不安装过滤驱动时候的坏文件产生率了 ，在这里再考虑避免坏文件的时候 可能在现有框架上做能取得的不会是最好的效果。

缓存的引入本身就增加了突然断电等突发事件时候数据丢失的可能。对付这些可能从外部去限制更好（比方强制客户增加ups？呵呵）。
多次备份 回滚 好像对于一般的数据没有多大的意义。
高标准 高安全 肯定是软硬结合的效果，可能单一的从所谓的文件系统去考虑解决不了这样的问题。可能是自己思路狭隘了。

呵呵，感谢ander5115 looksail cyliu的讨论。
欢迎大家各抒己见。

也许我们能在文件系统过滤中能过的最好程序就是 和没有安装我们以前达到同样的坏文件产生率，但是即便这样也会有用户责怪你，所以有必要做一个能降低坏文件出现率的东西。只是一些想法，能不能做 怎么做 我还没有想到，会不会去做我也不知道。

恩理论上应该可以做到文件的数据最小破坏
1：驱动里面的逻辑没有任何问题
2：对这次写的文件里面的数据 要对数据校验
3：这次写的文件不能是原始文件，写完后 在程序退出或者定时的rename成原始文件。
貌似OSR 那帮人写的东西 对着里面的逻辑实现了。

感谢qi 呵呵

没有人能保证绝对不写坏文件的 或者说即便是操作系统或者ntfs也不可能保证绝对没有数据损坏。
数据损坏是各个层面的 ，好的文件系统降低了磁盘引起坏文件的概率，好的文件过滤或许能降低文件系统出现坏文件的概率 但是现在来看 这样的产品不多。期待所谓的layer fsd吧。
任何事情都有回报率这样一个问题 ，所以考虑得失 更多的是没有人去做这样的事情 做的仅仅是最大限度的保证自己不出错！
looksai-“所以：必须保证你自己的代码不出问题，把逻辑吃透，不要奢望可以补救”

--浅见

呵呵 谢谢  各尽本分就好