FileSpy missing file writes from structured storage?

NTFSD
1

Hi!

In looking at the FileSpy operations, I can see my application (which does StgCreateDocFile and StgOpenStorage) open a file, do a couple of FileEndOfFile and FileAllocationInformation sets, then a few requests to get FileStandardInformation and FileBasicInformation (the archive bit is set as expected). Then I see a succession of FastIoLock and FastIoUnlock ops (maybe 15 in all), then we read the file, and I see the first maybe 100 bytes as all zero. All good so far. But then I see the file opened again, some lock ops performed on the file (one resulting in STATUS_LOCK_NOT_GRANTED), and then I see another succession of FastIoLock and FastIORead ops performed, and then I see a regular IRP_MJ_READ that has in the returned data buffer a bunch of info along the lines of 0xD0 CF 11 ED A1 D1 A1 E0…, most definitely not all 0’s as read before. What can this information be? What am I missing? There are NO writes that I can see that would account for this. Is this possibly extended attributes information-although this is a FAT drive, and hence support for streams is minimal? What information is the file system returning from this Read operation, and where could it be coming from? Any ideas?

Thanks!

Best,

Steve

2

> where could it be coming from?

Mapped sections?

wrote in message news:xxxxx@ntfsd…
Hi!

In looking at the FileSpy operations, I can see my application (which does
StgCreateDocFile and StgOpenStorage) open a file, do a couple of
FileEndOfFile and FileAllocationInformation sets, then a few requests to get
FileStandardInformation and FileBasicInformation (the archive bit is set as
expected). Then I see a succession of FastIoLock and FastIoUnlock ops
(maybe 15 in all), then we read the file, and I see the first maybe 100
bytes as all zero. All good so far. But then I see the file opened again,
some lock ops performed on the file (one resulting in
STATUS_LOCK_NOT_GRANTED), and then I see another succession of FastIoLock
and FastIORead ops performed, and then I see a regular IRP_MJ_READ that has
in the returned data buffer a bunch of info along the lines of 0xD0 CF 11 ED
A1 D1 A1 E0…, most definitely not all 0’s as read before. What can this
information be? What am I missing? There are NO writes that I can see that
would account for this. Is this possibly extended attributes
information-although this is a FAT drive, and hence support for streams is
minimal? What information is the file system returning from this Read
operation, and where could it be coming from? Any ideas?

Thanks!

Best,

Steve