STATUS_FILE_CORRUPT_ERROR in try to write EA on Srv03(SP1)

NTFSD
1

In our FSFD (attached to NTFS, VERIFIER level 0x7B) we overwrite files
extended attributes in successful
post-IRP_MJ_SET_INFORMATION(FileEndOfFileInformation), using PFILE_OBJECT
from “this” IRP_MJ_SET_INFORMATIO. In the described scenario we hit a
difference between W2K-SP4 and Srv03 (SP1 too), which is a matter of this
e-mail.

Here is description of FS and our actions:

In Pre-IRP_MJ_SET_INFORMATION(FileEndOfFileInformation) I query for current
FILE_STANDARD_INFORMATION, successful return and both (current)
AllocationSize and EndOfFile are (LONGLONG) 0, BOOLEAN DeletePending is
FALSE (0). The current IRPs(PFILE_END_OF_FILE_INFORMATION)
pIrp->AssociatedIrp.SystemBuffer is set to 64 bytes.
In successful post-IRP_MJ_SET_INFORMATION(FileEndOfFileInformation), I try
to overwrite (File already have EA) extended attributes of this PFILE_OBJECT
(sending IRP_MJ_SET_EA). The IRP_MJ_SET_EA fails with error code
STATUS_FILE_DELETED on W2K and STATUS_FILE_CORRUPT_ERROR on Srv03 (SP1).

Tracing FS activity shows that indeed there is an
IRP_MJ_SET_INFORMATION(FileDispositionInformation) for this file, from
different thread, right before
IRP_MJ_SET_INFORMATION(FileEndOfFileInformation) was sent. It makes sense
that write EA on deleted (or delete pending) fails as is the case on
W2K-SP4. But on Srv03 I get STATUS_FILE_CORRUPT_ERROR(0xC0000102) which
results in Application popup System Event log (Windows - Corrupt File
“$Mft”) instructing to run chkdsk.exe (Checkdsk.exe reports no error). I
traced also the open of this file and it was not open with
FILE_DELETE_ON_CLOSE.

The file is small 64 bytes, so I assume its disk storage is inside $MFT.

Described behavior is reproducible with MS Office Access 2003 and its
temporary files (.ldb), accessed over LanManager share.

Questions:

  1. Why different error codes (behavior) for same case between W2K and Srv03?
  2. Shouldn’t FILE_STANDARD_INFORMATION::DeletePending flag indicate that
    file was already disposition-ed?
  3. Is it a valid case that an
    IRP_MJ_SET_INFORMATION(FileEndOfFileInformation) is send with EndOfFile set
    to > (LONGLONG) 0, but the AllocationSize for this file is (LONGLONG) 0?

I already know I will have to fix it in our FSFD (:-)), but maybe some
explanation will help.

WBR Primoz