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:, 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 D0 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 with 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, all zeroes
20) IRP_MJ_READ, offset 0x10000, EOF 20) IRP_MJ_READ, offset 0x10000, EOF
21) FASTIO_UNLOCK_SINGLE 21) FASTIO_UNLOCK_SINGLE</http:>