Guy Hindell wrote:
[EMAIL PROTECTED] wrote:
Guy Hindell <[EMAIL PROTECTED]> wrote:
I would like to use sqlite (v3.3.8) on a linux box (fedora core 5)
to read/write a database file in a directory which is actually on a
windows share mounted via samba/cifs. I can open the file, and read
from it, but writing produces "disk I/O error" messages
(SQLITE_IOERR error code). I can write ordinary files on the share
(echo "foo" > [share]/file.txt) so it doesn't look like a
permissions issue. Only one process is ever going to access the file
so I wouldn't expect locking issues. If I try turning things around
so that I build/run my sqlite program on windows and access a file
on a samba share exported from my linux box I can read/write without
any errors.
Please turn on extended result codes using
sqlite3_extended_result_codes(db, 1)
Then tell me the detailed error code that results from this
error. That will help to isolate the problem.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
Hi, sorry for the delay - been away from email for a couple of days.
I have tried adding a call to sqlite3_extended_result_codes() as you
describe above (called once after the db file is opened on the handle
returned from sqlite3_open()). Still get simply error code 10
(SQLITE_IOERR) back from write statements (no upper bits set), but now
get no error text from sqlite3_get_table() (which I use to front all
my sqlite3_exec() calls).
What next?
guy
BTW, regarding the other post about file sizes greater than 2GB, no,
the file is tiny.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
OK, a bit more playing shows that the point at which the SQLITE_IOERR is
produced is in os_unix.c, line ~1586 -
lock.l_type = F_UNLCK;
lock.l_whence = SEEK_SET;
lock.l_start = PENDING_BYTE;
lock.l_len = 2L; assert( PENDING_BYTE+1==RESERVED_BYTE );
if( fcntl(pFile->h, F_SETLK, &lock)==0 ){
pLock->locktype = SHARED_LOCK;
}else{
rc = SQLITE_IOERR_UNLOCK; /* This should never happen <--- BUT IT
DOES :-(
}
Not sure why I don't see this as an extended result, but it seems like
the cifs mounted filesystem isn't behaving in the expected manner.
guy
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
