Hi!
I'm having a problem in my FSD, trying to support StgOpenStorage. Basically
I
can create a store okay, but when I go to try and read it with another call
to
StgOpenStorage call I get the error (0x80030050, already exists). More
specifically, I first create a store with STGM_TRANSACTED, STGM_READWRITE,
STGM_SHARE_DENYWRITE and STGM_CREATE. The StgCreateStorageEx call works
fine with these flags. But then when I try to get StgOpenStorage to work to
open that already opened store, I get the error 0x80030050). This works on
the FAT file system, but not in my own FSD.
I've spent quite a bit of time looking at the activity of StgOpenStorage.
When STGM_TRANSACTED and STGM_READ is indicated for an existing open DocFile
,
it seems like there is a cache read for the existing data, then a bunch of
lock
ops and then another cache read of size 0x200 with data that starts out as
0xFD
0xFF 0xFF 0xFF.... . Is this the two-phase commit process referred to here
<http://msdn2.microsoft.com/en-us/library/aa380017(VS.85).aspx>, where "a
table is updated in the file using a single-sector operation to indicate that
new data
is to be used in place of the old"? When I try this on a regular FAT
filesystem, filesys shows the second cache read to be the same as the first
(after the StgmOpenStorage is called to open a store that is already
opened).
When I try this on my own FSD, the second cache read shows the 0xFD 0xFF
0xFF... for the first 512 bytes. The StgmOpenStorage call then fails with
0x80030050 (already exists). What might the StgOpenStrorage be looking at to
determine if it can read the opened store, and why should it return the
"already exists" error? Why would this first reference for data in 0xFD 0xFF
0xFF... for the
first 0x200 bytes in cache happen for my FSD, and not for the FAT FSD (for
example?). Please note, I see no additional actual writes that start with
0xFD
0xFF..., but what I see is that in the second cache read, this data
mysteriously
gets put there, which I interpret to perhaps be the "single-sector
operation".
Thoughts?
Any help with this is greatly appreciated!!!
Best,
Steve
PS To recap, here is what happens in my FSD, and in FAT-pay attention to
steps
4,12, and 18:
FAT My FSD
1) StgCreateStorageEx - returns OK, 1) StgCreateStorageEx -
returns OK,
handle is left open (not closed before #2) handle is left open (not
closed before #2)
2) StgOpenStorage call to open #1 2) StgOpenStorage call to
open #1
3) IRP_MJ_CREATE returns OK 3) IRP_MJ_CREATE returns OK
4) IRP_MJ_READ first 0x200 bytes 4) IRP_MJ_READ first 0x200
bytes
buffer looks like 0xD0 CF 11 E0 A1.. buffer looks like 0xD0 CF
11 E0 A1...
5) FileBasicInformation: Attrib ARCHIVE 5) FileBasicInformation:
Attrib ARCHIVE
(I set the
ARCHIVE bit cuz FAT does)
6) FASTIO_LOCK 6) FASTIO_LOCK
7) FASTIO_LOCK 7) FASTIO_LOCK
8) FASTIO_UNLOCK_SINGLE 8) FASTIO_UNLOCK_SINGLE
9) FASTIO_LOCK - 9) FASTIO_LOCK -
STATUS_LOCK_NOT_GRANTED STATUS_LOCK_NOT_GRANTED
10) 4 FASTIO_LOCKs 10) 4 FASTIO_LOCKs
11) 4 FASTIO_UNLOCK_SINGLEs 11) 4 FASTIO_UNLOCK_SINGLEs
12) IRP_MJ_READ with DATA the SAME 12) IRP_MJ_READ ,DATA DIFFERENT!!!
as #4 Data starts
with 0xFD 0xFF 0xFF
13) FASTIO_LOCK 13) FASTIO_LOCK
14) FASTIO_LOCK 14) FASTIO_LOCK
15) FASTIO_UNLOCK_SINGLE 15) FASTIO_UNLOCK_SINGLE
16) FileStandardInformation 16)
FileStandardInformation
17) FileBasicInformation 17)
FileBasicInformation
18) FastIORead - SAME as #4 and #12 18) IRP_MJ_READ, buffer starts
with
"Root
Entry"
19) IRP_MJ_READ offset 0x1000, all zeroes 19) IRP_MJ_READ, offset 0x1000,
0's
20) IRP_MJ_READ, offset 0x10000, EOF 20) IRP_MJ_READ, offset
0x10000,EOF
21) FASTIO_UNLOCK_SINGLE 21) FASTIO_UNLOCK_SINGLE