Jacky Lam wrote: > I recently meet a case that the file position offset of a pager is beyond > EOF position of db.
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/lseek.html> says: | The lseek() function shall allow the file offset to be set beyond the end | of the existing data in the file. If data is later written at this point, | subsequent reads of data in the gap shall return bytes with the value 0 | until data is actually written into the gap. | [...] | Although lseek() may position the file offset beyond the end of the file, | this function does not itself extend the size of the file. [...] the only | function in POSIX.1-2008 that may directly extend the size of the file is | write(), truncate(), and ftruncate() | [...] | An invalid file offset that would cause [EINVAL] to be returned may be | both implementation-defined and device-dependent The sqlite3_file object does not have a concept of "current file position"; the xRead/xWrite/xTruncate functions have explicit offset/size parameters. But the Unix VFS internally takes advantage of this behaviour and writes only the last byte of a newly allocated page. > I would like to know if ... it is a bug makes from my OS What VFS are you using? Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
