Folder with sqlite db locked by explorer.exe after software uninstall - sqlite

I have an uninstall issue with an app which is using sqlite: during installation a blank sqlite db is created in [CommonAppData]\MyApp\mydb.sqlite, e.g. C:\Documents and Settings\All Users\Application Data\MyApp\mydb.sqlite. When I uninstall my app it can't delete the sqlite db, despite it removing the applications that are connectng to it. Using process explorer I can see that it's explorer.exe that has a lock on the MyApp folder (not on the sqlite file).
I've not seen this sort of thing before. Is it possible this is caused by the app not correctly closing/disposing of connections? I understand that at some level windows manages the fact that several threads & processes are accessing my db file, and it handles the locking. Is it possible that if my app isn't closing connections etc correctly then windows gets confused about whether the file is locked or not?
Or is that not possible and it must simply be something wrong with my MSI?
thanks for any suggestions!
UPDATE: not only can I not delete the folder or file, if I create a new file in that folder (e.g. a new txt doc) I can then not delete that file! So it's some wacky lock on the folder....
UPDATE: actually...it might just be permissions on that folder! In my msi i was setting permissions on that folder, and I think I didn't give delete rights so when I uninstalled I didn't have access to delete it :-/

Use handle.exe from the SysInternals collection to find out what has the remaining handle to the file.
It could also be your MSI, so check you are doing things in the right order by doing;
msiexec /u mymsi.msi /lv* mylog.txt

Related

macOS Catalina + Xcode 11 Error on reading file from project

After upgrading to macOS Catalina with latest Xcode 11, I am not able to read files directly from user path when doing unit testing, example:
PROJECT_DIR + "/FolderX/myFile.json",
I keep getting error Thread 1: EXC_BAD_ACCESS (code=1, address=0x8)
This is also happened when I am trying to open a couchbase lite database with custom path.
Error:
error opening!: 14
Cannot open database, Error : Error Domain=SQLite Code=14 "unable to open database file" UserInfo={NSLocalizedDescription=unable to open database file}
I believe this is an issue due to the read write access between my simulator and the latest Catalina.
My current workaround is to add my files and database to target membership and read the files directly from [NSBundle bundleForClass:[self class]].bundlePath.
Is there any better fix to this? Like tweaking any setting to allow it to read files from custom path like in older versions?
You might try looking in SystemPreferences > Security&Privacy > Privacy tab. From there, scroll down to "Files and Folders" <-- There's where you can see programs and the folders they have been granted access to in Catalina.
Personally, I didn't have time to waste figuring out how the new file permissions are supposed to work, so I let Xcode have full disk permission. (Right above the "files and folders" is "Full Disk Access".
Of course, that solved all my issues... after I get a chance to play with the new file permissions, I may revoke that access and give it explicit folder access.
Well if anyone is still struggling with this, I've moved all my projects outside of ~/Documents/
it is strange that projects under ~/Documents/ doesnt get asked for read permission, other paths do!
I end up putting all my projects under ~/workspace/
** for those who doesnt know, ~/ means /Users/{your username}/
Check your File Access settings in the App Sandbox in your project's settings, under Signing and Capabilities. For example, I couldn't access files in /Users/Bert/Downloads, even after turning on Full Disk Access in Security and Privacy in System Preferences. I had to grant read access to the Downloads Folder in App Sandbox settings.

Login and account registration broken on MVC application

Hello I'm new to MVC and have been looking for a solution to my problem for the last couple days with no avail.
I've created a simple blog engine using ASP.NET MVC, after installing it on IIS on my local PC, I quickly realized I needed a database for the login service to work.
So I elected to use LocalDB on a PC that I plan to use as a server. I moved my files over to the PC and installed everything I needed. As soon as I installed SQLExpress with LocalDB and reset the site, everything was working perfectly. However, I noticed some minor typos on a section of the site that's not easily edited. Stupidly, I reinstalled the website entirely from a new build instead of just updating the view that needed correction like a smart person would do.
Now every time I attempt to login to an excising account or create a new one I simply get the error
Cannot attach the file 'C:\inetpub\wwwroot\App_Data\aspnet-FacetBlog-20161020065352.mdf' as database 'aspnet-FacetBlog-20161020065352'.
From what I've learned, It's something to do with my LocalDB instance, but fixes I've found online seem to have no effect.
Admittingly, I'm pretty naive with it comes to SQL, so hopefully the fix is simple. If I've failed to provide vital information please tell me and I'll update the question. Additionally, an explanation of what exactly went wrong would be much appreciated. Thank you for your time.
When reinstalling your site, probably you had deleted database file aspnet-FacetBlog-20161020065352.mdf in your database directory. Since deleting MDF file doesn't affect registered SQL Express instance, SQL Express thinks the database still exists and trying to connect but failed.
First, try to attach the DB using SSMS query like this:
EXEC sp_attach_db #dbname=N'aspnet-FacetBlog-20161020065352.mdf', #filename1=N'App_Data\aspnet-FacetBlog-20161020065352.mdf', #filename2=N'App_Data\aspnet-FacetBlog-20161020065352.ldf'
NB: I assumed your MDF file location stands in App_Data directory, change it to your actual database directory.
If attempt to attach by query doesn't work, try these steps:
Stop IIS/IIS Express pool if it still running.
Open a Windows Powershell instance on your server PC (install it first if doesn't exist).
Run the following command:
sqllocaldb.exe stop v11.0
sqllocaldb.exe delete v11.0
sqllocaldb.exe start v11.0
Recreate the DB instance on your project, including data connection in Server Explorer (remove then create).
Re-run the project in development machine, then copy all required files to server PC. The database instance should be (re-)generated at this time.
Restart IIS/IIS Express pool on server PC.
Additionally you may run Update-Database command from Package Manager Console to ensure database integrity.
If those solutions still won't work altogether, simply rename your database files and attach it on your project, verify the connection string then retry step (5) and (6) above.
Related problems:
EF5: Cannot attach the file ‘{0}' as database '{1}'
Cannot attach the file ".mdf" as database "aspnet-"
Delete .mdf file from app_data causes exception cannot attach the file as database
Cannot attach the file 'C:\inetpub\wwwroot\MvcApplication10\App_Data\aspnet-MvcApplication10-20130909002323.mdf' as database 'aspnet-MvcApplication10-20130909002323'

Forgot to backup my database before reinstalling WAMP

I uninstalled and reinstalled my WAMP earlier today. I backed up my /www directory but totally forgot about my database (phpmyadmin). I didn't delete my C:/wamp directory, i just reinstalled on top of it.
Does this mean my databases are gone forever? Is there a way to retrieve them? Next time i'll know to export a dump of my databases before I meddle with the installation, I guess I had to learn this the hard way...
Thanks for your help.
That depends if you deleted the data directory or not. By default, wamp's data directory is c:/wamp/bin/mysql/mysql5.x.x/data check there and see if you have some folders with the names of your old databases. In those folders there would be a bunch of .frm, .MYD, and .MYI files assuming you are using myisam. If those files exist then you can recover. Just make sure the datadir in my.ini is pointing to the directory where your database are and restart mysql. It should fix itself automatically.
If you use innodb tables then it's a little more complicated but can be done. Those would be stored in files named ibdata1, ibdata2, etc.
If you don't have any of those files then I'm afraid you're out of luck.
I was able to retrieve mine on windows 7 by doing the following
Open Computer by clicking the Start button , and then clicking Computer.
Navigate to the folder that used to contain the file or folder c:/wamp/bin/mysql/mysql5.x.x/data
Copied it just in case I needed to revert
Right-click it, and then click Restore previous versions. ...
Double-click a previous version of the folder that contains the file or folder you want to restore.

SQLite error 'attempt to write a readonly database' during insert?

I have a SQLite database that I am using for a website. The problem is that when I try to INSERT INTO it, I get a PDOException
SQLSTATE[HY000]: General error: 8 attempt to write a readonly database
I SSH'd into the server and checked permissions, and the database has the permissions
-rw-rw-r--
I'm not that familiar with *nix permissions, but I'm pretty sure this means
Not a directory
Owner has read/write permissions (that's me, according to ls -l)
Group has read/write permissions
Everyone else only has read permissions
I also looked everywhere I knew to using the sqlite3 program, and found nothing relevant.
Because I didn't know with what permissions PDO is trying to open the database, I did
chmod o+w supplies.db
Now, I get another PDOException:
SQLSTATE[HY000]: General error: 14 unable to open database file
But it ONLY occurs when I try to execute an INSERT query after the database is open.
Any ideas on what is going on?
The problem, as it turns out, is that the PDO SQLite driver requires that if you are going to do a write operation (INSERT,UPDATE,DELETE,DROP, etc), then the folder the database resides in must have write permissions, as well as the actual database file.
I found this information in a comment at the very bottom of the PDO SQLite driver manual page.
This can happen when the owner of the SQLite file itself is not the same as the user running the script. Similar errors can occur if the entire directory path (meaning each directory along the way) can't be written to.
Who owns the SQLite file? You?
Who is the script running as? Apache or Nobody?
For me the issue was SELinux enforcement rather than permissions. The "read only database" error went away once I disabled enforcement, following the suggestion made by Steve V. in a comment on the accepted answer.
echo 0 >/selinux/enforce
Upon running this command, everything worked as intended (CentOS 6.3).
The specific issue I had encountered was during setup of Graphite. I had triple-checked that the apache user owned and could write to both my graphite.db and its parent directory. But until I "fixed" SELinux, all I got was a stack trace to the effect of: DatabaseError: attempt to write a readonly database
This can be caused by SELinux. If you don't want to disable SELinux completely, you need to set the db directory fcontext to httpd_sys_rw_content_t.
semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/railsapp/db(/.*)?"
restorecon -v /var/www/railsapp/db
I got this error when I tried to write to a database on an Android system.
Apparently sqlite3 not only needs write permissions to the database file and the containing directory (as #austin-hyde already said in his answer) but also the environment variable TMPDIR has to point to a (possibly writable) directory.
On my Android system I set it to TMPDIR="/data/local/tmp" and now my script runs as expected :)
Edit:
If you can't set environment variables you can use one of the other methods listed here: https://www.sqlite.org/tempfiles.html#temporary_file_storage_locations
like PRAGMA temp_store_directory = 'directory-name';
In summary, I've fixed the problem by putting the database file (* .db) in a subfolder.
The subfolder and the database file within it must be a member of the
www-data group.
In the www-data group, you must have the right to write to the
subfolder and the database file.
####### Additional Notes For Similar Problem #####
I gave write permissions to my sqlite database file to other users and groups but it still didn't work.
File is in my web root directory for my .NET Core WebApi.
It looked like this:
-rw-rw-rw- 1 root root 24576 Jan 28 16:03 librestore.db
Even if I ran the service as root, I kept getting the error :
Error: SQLite Error 8: 'attempt to write a readonly database'.
I also did a chown to www-data on the librestore.db and I still received the same error.
Finally I moved up above my webroot directory and gave others write access to that directory (LibreStore - the root of my WebApi) also and then it worked.
I'm not sure why I had to give the directory write access if the specific file already had write access, but this is the only thing that worked.
But once I made that change www-data user could access the .db file and inserts succeeded.
I got the same error from IIS under windows 7. To fix this error i had to add full control permissions to IUSR account for sqlite database file. You don't need to change permissions if you use sqlite under webmatrix instead of IIS.
I used:
echo exec('whoami');
to find out who is running the script (say username), and then gave the user permissions to the entire application directory, like:
sudo chown -R :username /var/www/html/myapp
(For followers looking for an answer to a similar question)
I'm building a C# .Net Core 6.0 WPF app. I put the Sqlite.db3 on the c:\ drive for convenience while developing. To write to the database I must open Visual Studio 2019 as Administrator.
#Charles in a comment pointed out the solution to this (or at least, a botch solution). This is merely me spelling it out more clearly. Put file_put_contents('./nameofyourdb.sqlite', null); (or .db, whichever you fancy) in a .php file in the root directory of your app (or wherever you want the db to be created), then load that page which renders the php code. Now you have an sqlite db created by whichever user runs your php code, meaning your php code can write to it. Just don't forget to use sudo when interacting with this db in the console.
A good clean solution to this is to allow the file of your main user account to be written to by (in my case) the http user but this worked for me and its simple.
None of these solutions worked for me and I suppose I had a very rare case that can still happen. Had a power shortage so even with 777 permissions on folder and db file, without SELinux, I would get this error.
Turns out there was a jellyfin.pid file (not sure if it's named after the service or user as they have the same name) locking it after the power shortage. Deleted it, restarted the service and everything worked.
I got this in my browser when I changed from using http://localhost to http://145.900.50.20 (where 145.900.50.20 is my local IP address) and then changed back to localhost -- it was necessary to stay with the IP address once I had changed to that once

Change SQLite database mode to read-write

How can I change an SQLite database from read-only to read-write?
When I executed the update statement, I always got:
SQL error: attempt to write a readonly database
The SQLite file is a writeable file on the filesystem.
There can be several reasons for this error message:
Several processes have the database open at the same time (see the FAQ).
There is a plugin to compress and encrypt the database. It doesn't allow to modify the DB.
Lastly, another FAQ says: "Make sure that the directory containing the database file is also writable to the user executing the CGI script." I think this is because the engine needs to create more files in the directory.
The whole filesystem might be read only, for example after a crash.
On Unix systems, another process can replace the whole file.
I solved this by changing owner from "root" to my own user, on all files in Database's folder.
Just do ls -l on said folder, and if any of the files is owned by root, just change it to your user, like:
# For each file do:
sudo chown "$USER":"$USER" /path/to/my-folder/file.txt
# Or "R"ecursive.
sudo chown -R "$USER":"$USER" /path/to/my-folder
(this error message is typically misleading, and is usually a general permissions error)
On Windows
If you're issuing SQL directly against the database, make sure whatever application you're using to run the SQL is running as administrator
If an application is attempting the update, the account that it uses to access the database may need permissions on the folder containing your database file. For example, if IIS is accessing the database, the IUSR and IIS_IUSRS may both need appropriate permissions (you can try this by temporarily giving these accounts full control over the folder, checking if this works, then tying down the permissions as appropriate)
This error usually happens when your database is accessed by one application already, and you're trying to access it with another application.
To share personal experience I encountered with this error that eventually fix both. Might not necessarily be related to your issue but it appears this error is so generic that it can be attributed to gazillion things.
Database instance open in another application. My DB appeared to have been in a "locked" state so it transition to read only mode. I was able to track it down by stopping the a 2nd instance of the application sharing the DB.
Directory tree permission - please be sure to ensure user account has permission not just at the file level but at the entire upper directory level all the way to / level.
Thanks
If using Android.
Make sure you have added the permission to write to your EXTERNAL_STORAGE to your AndroidManifest.xml.
Add this line to your AndroidManifest.xml file above and outside your <application> tag.
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
This will allow your application to write to the sdcard. This will help if your EXTERNAL_STORAGE is where you have stored your database on the device.
On win10 after a system crash, try to open db with DB Browser, but read only.
Simply delete the journal file.
In Linux command shell, I did:
chmod 777 <db_folder>
Where contains the database file.
It works. Now I can access my database and make insert queries.
On Windows:
tl;dr: Try opening the file again.
Our system was suffering this problem, and it definitely wasn't a permissions issue, since the program itself would be able to open the database as writable from many threads most of the time, but occasionally (only on Windows, not on OSX), a thread would get these errors even though all the other threads in the program were having no difficulties.
We eventually discovered that the threads that were failing were only those that were trying to open the database immediately after another thread had closed it (within 3 ms). We speculated that the problem was due to the fact that Windows (or the sqlite implementation under windows) doesn't always immediately clean up up file resources upon closing of a file. We got around this by running a test write query against the db upon opening (e.g., creating then dropping a table with a silly name). If the create/drop failed, we waited for 50 ms and tried again, repeating until we succeeded or 5 seconds elapsed.
It worked; apparently there just needed to be enough time for the resources to flush out to disk.
On Ubuntu, change the owner to the Apache group and grant the right permissions (no, it's not 777):
sudo chgrp www-data <path to db.sqlite3>
sudo chmod 664 <path to db.sqlite3>
Update
You can set the permissions for group and user as well.
sudo chown www-data:www-data <path to db.sqlite3>
If <db_name>.sqlite-journal file exists in the same folder with DB file, that means your DB is opened currently and in the middle of some changes (or it had been at the moment when DB folder was copied). If you try to open DB at this moment error attempt to write a readonly database (or similar) could appear.
As a solution, wait till <db_name>.sqlite-journal disappears or remove it (is not recommended on the working system)
I had this problem today, too.
It was caused by ActiveSync on Windows Mobile - the folder I was working in was synced so the AS process grabbed the DB file from time to time causing this error.
On Linux, give read/write permissions to the entire folder containing the database file.
Also, SELinux might be blocking the write. You need to set the correct permissions.
In my SELinux Management GUI (on Fedora 19), I checked the box on the line labelled httpd_unified (Unify HTTPD handling of all content files), and I was good to go.
I'm using SQLite on ESP32 and all answers here are "very strange"....
When I look at the data on the flash of the ESP I notice there is only one file for the whole db (there is also a temp file).
In this db file we have of course the user tables but also the system tables so "sqlite_master" for example which contain the definiton of the tables.
So, it's seems hard to belive this can be a "chmod" problem, because if the file is read only, even creating table would be impossible as SQLite would be unable to write the "sqlite_master" data...
So I think our friend user143482 is trying to acesse a "read only" table. In SQLite source code we can see a function named tabIsReadOnly with this comment:
/* Return true if table pTab is read-only.
**
** A table is read-only if any of the following are true:
**
** 1) It is a virtual table and no implementation of the xUpdate method
** has been provided
**
** 2) It is a system table (i.e. sqlite_master), this call is not
** part of a nested parse and writable_schema pragma has not
** been specified
**
** 3) The table is a shadow table, the database connection is in
** defensive mode, and the current sqlite3_prepare()
** is for a top-level SQL statement.
*/

Resources