Kiran,
I understand where you are coming from with this.
With that said here are my thoughts:
1. It is not sqlite's responsibility to make sure that your db is writable.
After all either you/and/or the application has made it not writeable. Sqlite
has a reasonable expectation that underlying file permissions are not changed
in the middle of a transaction.
2. Other DB vendors do not generally allow the user to modify the underling
files nor their permissisions. An error would be generated. The fact that
sqlite is throwing a busy error is your error code and allows you to test/check
for permissions issues in your application busy handler code.
A solution for your case would be to write and install your own busy handler
that also performs a file system check of the permissions. You can then at your
own discretion either terminate the transaction or reset the permissions
appropriately.
For unix systems:
int chmod(const char *path, mode_t mode);
HTH
Kiran <[EMAIL PROTECTED]> wrote: All, Let me confess that the topic has changed
a bit from "how to solve" to
"why should this occur" scenario.
Now suppose my Linux system already has a DB with "444" permission (say I
copied from another Linux machine) and tried running my application, then I
want to trap the read-only (unable to write) scenario.
This is one of the few scenarios I can think of.
Like this there might be N number of scenarios wherein we may encounter some
sort of issue with DB.
So my (might I say holistic view) question is if sqlite3_exec is unable to
differentiate a busy_handler trigger due to permission other related issues
and DB lock, won't we get ourselves into some mis-leading (ambiguity)
scenario.
Regards,
Kiran
-----Original Message-----
From: Ken [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 08, 2007 8:00 PM
To: sqlite-users@sqlite.org; [EMAIL PROTECTED]
Subject: RE: [sqlite] File Permission and Busy Handler Issue in SQLite
What is the goal of changing permissions?
Kiran wrote: The interesting part of the scenario
is, when you change the file permission
using chmod 000 bulk.db, there is no effect on the process of writing (with
sqlite3_exec and busy handler combo) however the same does not work for the
chmod 444 bulk.db.
This make me suspect that there is some point which I am missing or may be
it is a defect in SQLite.
Anyways thanks for effort Joe
-----Original Message-----
From: Joe Wilson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 08, 2007 6:53 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] File Permission and Busy Handler Issue in SQLite
It is not reasonable to change a database file to read-only in the
middle of a transaction. I suppose sqlite could be changed to detect it,
but why bother?
By the same logic, if another process wrote random bytes in the middle
of an sqlite database file, should sqlite be responsible for recovering
from that as well?
--- Kiran wrote:
> I am currently using SQLite in my application as in Multi-process
> environment. I.e. my application will contain multi-process which will
> handle add/delete request to a single db - (bulk.db). I am using the
> busy_handler concept (with 5ms delay) for locking issues.
>
> However, during testing, when 5 processes is up and running, I by chance
> changed the file permission of bulk.db (chmod 444 bulk.db) to read only.
Now
> I see that the sqlite_exe is not able to trap the read-only mode error of
> the database (while it tries to add records) and is just returning a
> busy_handler and thus in loop.
>
> Bottom line, if you are using busy_handler and if DB file permission is
> changed to read-only (manually) instead of throwing an error, SQLite will
> continue triggering busy_handler. Thus not able to handle this situation.
____________________________________________________________________________
________
Choose the right car based on your needs. Check out Yahoo! Autos new Car
Finder tool.
http://autos.yahoo.com/carfinder/
----------------------------------------------------------------------------
-
To unsubscribe, send email to [EMAIL PROTECTED]
----------------------------------------------------------------------------
-
----------------------------------------------------------------------------
-
To unsubscribe, send email to [EMAIL PROTECTED]
----------------------------------------------------------------------------
-
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
