FlushFileBuffers是否一定需要执行？

linsoo 2010-09-09 07:38:26

我现在有个程序频繁的往dbf文件写记录(WriteFile)，写完一条记录之后，是否一定需要执行FlushFileBuffers？

同步会有另为一个程序不断的读取这个文件。那么如果我不执行FlushFileBuffers，会否对读取记录造成影响？

比如读取到了半条记录之类的。

由于FlushFileBuffers的速度很慢，导致整个写dbf的速度很慢，所以想考虑吧FlushFileBuffers去掉。

谢谢大家。

...全文

1971 10 打赏收藏转发到动态举报

写回复

用AI写文章

10 条回复

切换为时间正序

请发表友善的回复…

发表回复

Waiting4you 2010-09-10

打赏
举报

不执行FlushFileBuffers，不会对读取记录造成影响。

写文件有缓冲机制，这样可以提高读写速度，如果写完就Flush，相当于缓冲机制被取消了，当然变慢了。我想原程序这样写的目的应该是防止意外关机（如断电）造成的错误。

jone7319 2010-09-10

打赏
举报

不用每次都用FlushFileBuffers，它占用系统资源。

Waiting4you 2010-09-10

打赏
举报

[Quote=引用 9 楼 linsoo 的回复:]

引用 7 楼 ccrun 的回复:

第四参数的返回值和写入长度一样，说明写完整了。
另外，写成功的话，WriteFile函数返回true

两者一结合就行了。

再问一个问题哈，加入连续进行了5此WriteFile，最后一次判断第四个参数和最后一次写入的字节数是相同的，是不是代表之前的4次也肯定是写入完成的？
[/Quote]
如果对写入的准确性要求很高，为什么不每次判断？要知道IO的速度比CPU慢得多，你每次对比判断也不会浪费多少速度。
另外，对于你之前的写操作一半在缓存一半的磁盘的假设，要知道读也是首先从缓存里读的，所以不会有问题。

linsoo 2010-09-10

打赏
举报

[Quote=引用 7 楼 ccrun 的回复:]

第四参数的返回值和写入长度一样，说明写完整了。
另外，写成功的话，WriteFile函数返回true

两者一结合就行了。
[/Quote]

再问一个问题哈，加入连续进行了5此WriteFile，最后一次判断第四个参数和最后一次写入的字节数是相同的，是不是代表之前的4次也肯定是写入完成的？

linsoo 2010-09-10

打赏
举报

[Quote=引用 7 楼 ccrun 的回复:]

第四参数的返回值和写入长度一样，说明写完整了。
另外，写成功的话，WriteFile函数返回true

两者一结合就行了。
[/Quote]
哦，多谢，我给想岔了...

ccrun.com 2010-09-10

打赏
举报

第四参数的返回值和写入长度一样，说明写完整了。
另外，写成功的话，WriteFile函数返回true

两者一结合就行了。

linsoo 2010-09-10

打赏
举报

[Quote=引用 1 楼 ccrun 的回复:]

API：WriteFile的第4个参数，返回写到文件中的字节数。判断这个字节数和要写入的缓冲长度是否相等再结合WriteFile函数的返回值，如果成功的写到了文件中，可以不用每次调用FlushFileBuffers。
[/Quote]
我测试了一下发现第四个参数返回值和写入的长度总是一样的，所以如果这么判断，仍然是每次都会调用FlushFileBuffers

linsoo 2010-09-10

打赏
举报

[Quote=引用 4 楼 waiting4you 的回复:]

不执行FlushFileBuffers，不会对读取记录造成影响。

写文件有缓冲机制，这样可以提高读写速度，如果写完就Flush，相当于缓冲机制被取消了，当然变慢了。我想原程序这样写的目的应该是防止意外关机（如断电）造成的错误。
[/Quote]
因为每条记录的长度是固定的，比如1024字节，我怕如果不执行会不会WriteFile之后会不会有可能前512字节已经实际写到磁盘上了，还有512字节还在缓存里，而读取的时候是读取1024字节的，从而造成读取失败。是不是不存在这种可能性？

[Quote=引用 4 楼 waiting4you 的回复:]

不执行FlushFileBuffers，不会对读取记录造成影响。

写文件有缓冲机制，这样可以提高读写速度，如果写完就Flush，相当于缓冲机制被取消了，当然变慢了。我想原程序这样写的目的应该是防止意外关机（如断电）造成的错误。
[/Quote]
那么说意外断电才可能出现写了一半的情况？

谢谢大家的解答～