Hi,
This is more of a heads up than anything else. I'm developing an app
that writes to files using the Windows API. I actually used some code
from the SQLite file library hence this message.
The code snippet is:
// Try to open existing file
h = CreateFileA(path,
GENERIC_WRITE,
0,
NULL,
CREATE_NEW,
(FILE_ATTRIBUTE_NORMAL | FILE_FLAG_SEQUENTIAL_SCAN),
NULL);
if(h == INVALID_HANDLE_VALUE )
{
...
}
// Try and lock the file for writing
ULARGE_INTEGER bytesToLock.QuadPart = 2147483648; // 2^31
if (LockFile(h, 0, 0, bytesToLock.LowPart, bytesToLock.HighPart) == 0)
{
...
}
The app keeps the file locked until completion. The app takes a few mins
to run so I thought I test the locking. I opened Explorer and then
opened the file in Wordpad. Add a few garbage words and hit 'Save'. To
my surprise it had saved. I could confirm this by closing and reopening
the file in Wordpad seeing the change.
I checked my code and also tried commenting out the LockFile call (just
using the CreateFile call with the SharedMode parameter set to 0). Still
the same result.
I then changed the directory the app was writing to the local hard
drive. This time I got the usual "This file is opened by another
process..." popup when trying to open in Wordpad. So the difference was
the output directory.
It so happened that the output directory was on a network drive that had
been "Made available offline" (not sure its proper term) and was offline
at the time the app was running.
I then changed the output directory of the app to another online network
drive. Again, this time I got the usual "This file is opened by another
process..." popup when trying to open in Wordpad.
So unless someone could point out either a code/human error, I believe
locking capabilities are nonexistent for network drives that are have
file synchronisation enabled and are in offline mode.
Obviously DRH needs to verify but I'd imagine this could be a problem if
you use a multi-thread/multi-process application accessing a SQLite db
on a particular (though unlikely) network setup described above.
Regards
Nick
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
