I am looking at the code in os_win.c for sqlite3WinOpenReadWrite() and have a question. The routine uses the windows API CreateFile() to open the file. First it checks to see if it can open it read/write and then if that fails, it tries read-only.
Now, when it tries read/write, it uses FILE_SHARE_READ|FILE_SHARE_WRITE as the share parameter, and when it tries read-only, it uses FILE_SHARE_READ. According to logic and the windows documentation, this precludes the current process or any other process on this or any other machine from subsequently opening the file read/write. Is this the desired behavior? If so, why? I would think that there would be a normal state of affairs where some clients are read-only and some are read/write. If the above is true and I am not missing something, then in some instances, those with the access rights can sometimes open the database read/write (if a read-only process has not already opened it) and sometimes not.
