From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Stephan Beal > seek() allows one to seek past the end of the file, so the problem is not > with seek (unless sqlite3's VFS interface castrates it), but probably a > follow-up read() after the seek. It is perfectly legal, generically > speaking, to fseek(f,100,SEEK_END) followed by a write() (which would grow > the file, permissions allowing).
Oops, you're right, I/O error is generated by read() call, not seek() one. >...barrier=1 and do not disable the write cache so most Linux distributions > are vulnerable to this problem. Note that this is an operating system and > hardware issue and that there is nothing that SQLite can do to work around > it. Other database engines have also run into this same problem." > > But notice those last two sentences. The sentence starts with: " We are told that most Linux distributions do not use barrier=1 and do not disable the write cache so most Linux distributions are vulnerable to this problem." I managed the FS mount option and this partition is mount write-back mode with barrier=1. That's the critical point: referring the documentation, this configuration should be safe enough. How can I get wrong file size or wrong page nb in the header? --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
