关于写文件时突然断电

Question

假定文件已经有一个字节(假定为48)我打开此文件
然后把文件指针移动动末尾
写一个字节(假定为49)
关闭文件
在这个过程断电了.
这个文件是不是只有两种情况.
一,只有一个字节(内容为48)。
二，有两个字节（内容为48,49)。会不会有第三种情况：
比如第二个字节只写了一位(bit)，就断电了

Answer 1

"在这个过程断电了",如果系统有掉电中断（即220掉电，但系统还能运行一段时间，这段时间，我设计时要求>30ms），文件不会损坏，内容难说。
否则“Anything is possible！”

Answer 2

电路设计的话，个人觉得一个bit太慢，想想一个8bit并联的拷贝就可以提高8倍速度，硬件上应该早就解决这种问题，更有可能是32位一起，觉得是32位机器的缘故吧

Answer 3

虽说单核时代是串行的，但是最小串行的单元应该不是一个bit吧，个人觉得一个累加器的位数就代表着最小工作单元，不排除一些其它特殊用途的硬件设计。

Answer 4

我的初步想法是不用考虑这些问题
因为这些问题是操作系统或VC考虑的问题我们调用CFile的Write函数,他要么成功,要么失败,如果他把文件损坏了,是MS的责任

Answer 5

我们也要考虑断电的问题 
因为，我们写文件的时候，
可能（实际上几乎是100%)多次调用CFile类的Write 
Write了前几次就断电了
后面的就没执行 
于是这个文件就损坏了 
文件close的时候会加文件结束符
如果突然断电，来不及close就没结束符 
这样问题，我们必须考虑 

Answer 6

那就每次write，然后close，可以避免一些问题

Answer 7

加上ups电源
不过一般PC不需要吧

Answer 8

这个问题有意思，呵呵
做做实验呢？
实验出每次突然断电之后能写的“最小有效字节数（或者）bit位，然后根据这个再写文件的时候设定有效标志，避免读取到错误的数据。不过胡斯乱想了一下，又觉得似乎没这个必要，你设定一个以‘字节’为单位的文件‘文件结束标志’，然后周期写入，假设意外断电了，结束标志没有正常写入，那么找到最后一个有小‘文件结束标志’……或者你根据文件字节数来判断，比如8个字节那就是64bit，一旦出现65bit，那最后一个就不要了……其实应该避免这种意外断电的情况。

Answer 9

    从软驱时代，文件就已经按“块”读/写了，每次读/写一个分配单元（很长时间以来都是512字节）。    关于写文件时断电的应对，一般是使用一个临时文件，编辑改动记录在临时文件中，存盘时将改动部分写入目标文件，确定成功后，再删除临时文件（或者标记已经保存）。这个方案我们常见的就是windows上面MS Word和linux上面的vi等字编辑软件了。这两个软件的这种机制，说明了在应对写文件时断电后文件完整性上，除此以外，没有什么特别好的办法。在数据库设计中，文件完整性和一致性始终是至关重要的，数据库使用“事务”来机制来提供保证，在底层，通过数据转储，冗余校验，登记日志等方法来实现数据库安全性的强保证的。

Answer 10

那就每次write，然后close，可以避免一些问题
----
正Write的时候断电了哦

Answer 11

除非你人为让它写一位。按你的问题，还有种可能。因为一般写文件是两个过程，先缓存，然后Flush。有可能Flush的时候断电，导致什么都没有写。

Answer 12

http://topic.csdn.net/u/20101003/10/a41a6083-aa99-40dd-96b8-d1823a2ac31e.html?96

Answer 13

不可能只写一个bit，os会整簇写。