----- Original Message -----
From: "Dennis Jenkins" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Friday, August 26, 2005 1:48 PM
Subject: Re: [sqlite] checking the database status
Robert Simpson wrote:
What I say below is in no means trying to be rude or show you (or anyone)
up. I have no idea what your experiences are with Windows or Unix or
Unix-Like operating systems. I'm probably stating things that almost all
of us already know. :)
I've been coding for about 24 years, the last 15 on a PC ... so as vast as
my experience is with DOS/Windows, there is only one truism that I hold to:
There is always someone out there who knows more than I do.
In Unix you can delete an open file. The file is simply removed from the
directory. Properly, this is called "unlinking". The actual syscall is
called "unlink". When a file has 0 hard-links, and no process has it
open, it is removed from the file system and the space reclaimed. Normal
files have only one "hard-link". The 'hard-link' count is stored in the
file's inode in a traditional unix file system. (I know about UFS and
EXT2/EXT3. I have no idea what JFS, XFS, ReiserFS, et al do.)
As I said, I am not familiar with *nix environments, so my comments are (as
always) subject to platform corrections.
In Windows you can not delete an open file, even if your process has the
file open for writing. The text at the bottom was lifted directly from
the February 2003 Win32 platform SDK on the "DeleteFile" API call [1]
about 15 seconds ago. Note that the rules I'm discussing are for NT
kernel based versions of Windows.
Because of this behavior, at least in Windows, it is permissable to
create/open a file, keep it open, call sqlite3_open() and then close your
handle, and know that the operation you performed on the file was for all
intents and purposes, atomic.
I know :) I'm simply saying that I wish that sqlite3_open() took some
flags and "did the right thing" based on the underling OS. Those flags
would be specific to sqlite and translated into the native OS flags deep
inside to "os_***.c" wrappers.
#define SQLITE3_OPEN_DEFAULT 0
#define SQLITE3_OPEN_EXISTING 1
#define SQLITE3_OPEN_TRUNCATE 2
...etc...
So my question is simply, "Why was sqlite3 designed to behave the way it
does?" (That is, the caller has no control over the underlying "open"
operation.
Another option would be to create a version of "sqlite3_open" that takes
an existing OS handle and uses the handle as-is (I suppose that you'd
still have to pass in a filename so that the journal, vacuum, (and
other?), files could be created).
Now, I've not had a need for any of this. I did notice this a long time
ago though. If I really needed this, I'd code it myself. I've already
hacked away on the sqlite code base to make it do some things that I want
it to do.
I agree, it would've been nice to have more control over the potential
creation of a new file during the call to open.
[snip]
The *DeleteFile* function fails if an application attempts to delete a
file that is open for normal I/O or as a memory-mapped file.
*Windows Me/98/95: *The *DeleteFile* function deletes a file even if it
is open for normal I/O or as a memory-mapped file. To prevent loss of
data, close files before attempting to delete them.
To recursively delete the files in a directory, use the *SHFileOperation*
function.
To close an open file, use the *CloseHandle* function.
The *DeleteFile* function marks a file for deletion on close. Therefore,
the file deletion does not occur until the last handle to the file is
closed. Subsequent calls to *CreateFile* <createfile.htm> to open the file
fail with ERROR_ACCESS_DENIED.
Here the MSDN documentation may be faulty or misleading. I verified in
Windows 98 that if you attempt to call DeleteFile() on a file that is open,
the file will not be deleted as the documentation seems to state. Not only
that, but the file is not marked as delete-on-close either as the
documentation seems to state. I tested on 98 and 2003 with FAT and NTFS
volumes respectively. The test consisted of two processes opening the same
file (one gets it, the other fails to create) then having both processes
attempt to delete the file before the file creator's file handle is closed.
This behavior is consistent with all my previous observations of Windows and
how it deletes files.
Robert
