On 11 Nov 2010, at 4:05pm, Dennis Suehr wrote: > I need to implement a function which will be able to delete a previously > created database. I plan to do this by obtaining an exclusive lock to the > DB, then closing my connection (which as I understand will still keep the DB > locked) and then removing the DB file (and related SQLite temp files) from > the underlying file system. > > I have a couple of concerns regarding this operation, which are as follows: > > 1) Firstly, I can not seem to ascertain what would happen to another process > which held an open database handle to the now deleted DB if it tried to > perform a subsequent operation on it. If some appropriate error code is > returned upon which I can act, then great. However, it goes without saying > that a seg fault would not be an appropriate outcome > > 2) Ideally, I would like to be able to force close any open connections > before deleting the database file and if that's not possible then at least > being able to clean up any SQLite related memory resources from those other > connection afterwards. However, I can not even find any existing SQLite > mechanism which would provide me with a list of open connection handles to a > given DB.
The reason you can't find this in SQLite documentation is that it's done at the OS level. The answer depends on which operating system and which file system you're using. Let us assume that you are accessing these files directly from a hard disk rather than across a network. Then you are using perhaps FAT, NTFS, ext3, HFS+, or some other disk filing system. Under early versions of Windows using FAT or NTFS, if you had a file open without an active lock, the file could be deleted. The application with an open handle would receive an error the next time it tried to do anything with that handle (sometimes including 'close' !). There have been two other changes since early versions of Windows, but I don't remember where they each happened. However, current versions of Windows are POSIX compliant and act the same as Unix systems. POSIX systems (which include all the versions of *n*x you're likely to find including Mac OS X) use a system of hard links: one file on disk may have many hard links to it (appear under different names and in different directories). So a file should be deleted only when the last hard link to it has been deleted. However, a hard link is created each time an application opens the file: that's what the file handle points to. So if two apps have the file open there would be three hard links to the file, and deleting its entry in a disk directory leaves two hard links, so it doesn't delete the file and reclaim the disk space. BUT ... the file will no longer be shown if you list the contents of its directory. There's nothing to stop someone in the meantime creating a new file with the same name, and using an app to open that one. So it's possible for two applications to have open two different files of the same name in the same directory. Other (embedded ?) disk operating systems and can all have their own rules about this. And as I wrote earlier, network filing systems have their own rules about this. To complicate things, one computer might be accessing the file directly from disk, but another might be accessing the same file through a SMB/SAMBA/NFS/whatever network connection. Which is one reason we tell people never to do that. So assuming direct access from a hard disk and a fairly recent OS we get the following answers: 1) The file would not actually be deleted yet. The original file would still exist and the process can continue to read/write it. When the last app closes the file the OS will notice, really delete the file, and reclaim the filespace as unused space. No seg faults because there are no errors. 2) No. There's no way to tell all applications with a certain file open that it's going to disappear. If you write all those apps yourself you could come up with any number of semaphore mechanisms, but most OSen don't provide anything like that. SQLite definitely can't tell what files it really has open because there's no way for the OS to tell it: it works differently for each OS. The above is simplified for brevity (e.g. Mac OS X actually does have a notification mechanism for a file disappearing) but should give you something to go on. If you have specific questions, get back to us. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
