Hi- For the method: static int unixTruncate(sqlite3_file *id, i64 nByte)
It seems like an easy fix would be: 1.) Check size of file 2.) If file size is less than or equal to nByte, call ftruncate. 3.) Else, lseek to position nByte-1 and then write a NULL character at that position. That will quickly expand the size of the file to desired size. However, I think the fill for the file will be random. So, the question would be: Is it ok for the data in the extended portion of the file to be something other than NULL characters? Does SQLite already know that this area of the file is not valid, or does it assume (from the ftruncate documentation) that the file will be zero-extended? Thanks, Mark > -----Original Message----- > From: Joe Wilson [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 29, 2007 9:28 AM > To: [email protected] > Subject: Re: [sqlite] ftruncate() for values greater than file size > > > > On Nov 29, 2007, at 9:19 PM, Mark Brown wrote: > > > I have finally tracked down a bug that has plagued by vxWorks > > > port. It > > > appears that our file system's implementation of > ftruncate() does > > > not like > > > to "truncate" a file larger than its current size, and returns > > > EINVAL for > > > this operation. > > This is interesting - ftruncate's behavior is not defined by POSIX > in this case. SQLite shouldn't rely on the commonly implemented > zero-fill extension. > > http://www.opengroup.org/onlinepubs/007908799/xsh/ftruncate.html > > "If the file previously was larger than length, the extra data is > discarded. If it was previously shorter than length, it is > unspecified > whether the file is changed or its size increased." > > One could easily write a wrapper function for ftruncate and use it > instead. ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
