Re: [sqlite] offset of file position is beyond EOF

[J Decker]

On Sat, Aug 19, 2017 at 4:44 AM, Jacky Lam  wrote:

> I implement my own vfs analogous to the vfs like fopen, fclose, fseek,
> fwrite, fread and etc.
> When I iterate a sql statement up to millions records, the fwrite fail due
> to pos of fseek is beyond the eof position.
> I am wondering whether the pos sometimes beyond eof is normal.
> If it is normal, I can do some tricks to write beyond the eof position.
>
> it is normal.  To extend a file; fseek() and then write.
there is no mandate that fseek be within the file; the file is expected to
zero-fill from the end up to the position to write.


>
> On 2017年8月19日週六 下午5:13 Clemens Ladisch  wrote:
>
> > Jacky Lam wrote:
> > > I recently meet a case that the file position offset of a pager is
> beyond
> > > EOF position of db.
> >
> > 
> > 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
> >
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] offset of file position is beyond EOF

[Jacky Lam]

I implement my own vfs analogous to the vfs like fopen, fclose, fseek,
fwrite, fread and etc.
When I iterate a sql statement up to millions records, the fwrite fail due
to pos of fseek is beyond the eof position.
I am wondering whether the pos sometimes beyond eof is normal.
If it is normal, I can do some tricks to write beyond the eof position.


On 2017年8月19日週六 下午5:13 Clemens Ladisch  wrote:

> Jacky Lam wrote:
> > I recently meet a case that the file position offset of a pager is beyond
> > EOF position of db.
>
> 
> 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
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] offset of file position is beyond EOF

[Clemens Ladisch]

Jacky Lam wrote:
> I recently meet a case that the file position offset of a pager is beyond
> EOF position of db.

 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

[sqlite] offset of file position is beyond EOF

[Jacky Lam]

Hi All,
I recently meet a case that the file position offset of a pager is beyond
EOF position of db.
I would like to know if it is normal or it is  a bug makes from my OS (
SQLITE_OS_OTHER=1)?

Thanks.

Jacky
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users