On 2014/02/10 21:18, C M wrote:
Documents\My Dropbox\myapp\gorp.db-journal) - Access is denied. (3338)
SQLITE_IOERR
SQLITE_LOG: statement aborts at 16: [SELECT resumes, start FROM
WHERE start='2014-02-07 14:24:14.064000' AND value='activity'] disk I/O
error (3338) SQLITE_IOERR
Looks like GetFileAttributesEx() might be throwing an ERROR_ACCESS_DENIED
exception. Maybe a virus scanner or some other background process had
temporarily locked the database file.
Dan.
I agree, and I think Dropbox is the culprit here.
May I ask either Dan or Kees, or anyone here, how to go from the error
codes to that diagnosis?
Kees, why do you think Dropbox is the culprit?
I may want to deploy this app to users who would also backup their database
by having it in the Dropbox folder. What would people suggest I do about
this?
How to go from the error codes to the diagnosis? I think the logic is as
follows:
We can see an error occurs when trying to access the file, or more specifically, trying to obtain a shared lock on it. This means it
is locked by another application (as opposed to another SQLite thread). Now the question remains which other application? We would
usually simply suggest to look in your system, but you already provided a log of the error, and it is clear from the error that a
file you are trying to access is in "Documents\My Dropbox\myapp\" which, as everyone knows, is a dropbox folder, which means likely
you have dropbox installed. Secondly, Dropbox is a known culprit in this regard, because it syncs files with the cloud (it is not
the only one, Skydrive, Google drive etc all do this), which means it will have to lock a file while either uploading or
download-syncing it for consistency and concurrency reasons. Put these three pieces of evidence together, and the answer is
inevitable - you probably have dropbox problems.
The remedy is not easy - same as when dealing with Excel exports or some other system that will lock files of it's own volition if
it is opened with that system - simply making a byte-copy of the file, changing it and replacing it afterwards, with a possible
replace-queue facility which will wait till a lock is released. Problem is, what if the other app made changes that you actually
mean to keep?
To put this into your perspective, what if the file was dropboxed, altered on another machine of the user's, or by another user
(through a dropbox share), and is now updated in the cloud and due to sync back? Whatever solution, versioning-control or other
system you come up with to handle this, it has to be full of user-informative messages and you can never keep an editable file where
locking might be a problem inside a dropbox (or other locking+syncing) folder.
It is better to have a DB file (meaning a file that gets small incremental changes over time as opposed to a load-once, save-once
methodology) in a place that is not affected by locks, and sometimes exporting (using the SQLIte backup facility maybe) to the
dropbox or shared folder so it gets propagated to the cloud... Using it within that folder is just not feasible.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
