>Sometimes the filter’s postwrite fails with error STATUS_FILE_LOCK_CONFLICT
I think that this is a request from the Cache Manager’s lazy writer thread. If you provided the call stack, this would be more clear.
The reason is that you call objMemoryMappedFile.Open( …, FileSize ), some FSDs initialize the cache for a file while changing the file size.
The CacheManager tries to flush the cached data and calls MmFlushSection() which flushes dirty pages, but the FSD knows that the call from the Cache Manager and checks the Valid Data Length that has not been changed and fails the request. The Valid Data Length will be changed when the write request from the Memory Manager’s Mapped Page Write( i.e. the Memory Manager’s thread or direct invocation of MmFlushSection() by the user ) is received.
The System doesn’t purge or lost the page frame if the STATUS_FILE_LOCK_CONFLICT is returned to the Cache Manager.
–
Slava Imameyev, xxxxx@hotmail.com
“ganesh pashupathi” wrote in message news:xxxxx@ntfsd…
Hi,
I am running following test application with my filter driver loaded. Sometimes the filter’s postwrite fails with error STATUS_FILE_LOCK_CONFLICT(0xC0000054).
Following is my test application.
CFile objFile(“c:\temp\Test.txt”, CFile::modeReadWrite | CFile::modeCreate | CFile::shareDenyNone);
for nIndex = 0 to nCount
{
//Class provided by Microsoft…
CMemoryMappedFile objMemoryMappedFile;
//cWriteData contains the data to be written…
objMemoryMappedFile.Open(“MapFile”,
objFile.m_hFile,
4,
0,
strlen(cWriteData));
objMemoryMappedFile.Write(cWriteData,strlen(cWriteData));
objMemoryMappedFile.Flush();
objMemoryMappedFile.UnmapViewOfFile();
objMemoryMappedFile.Close();
objFile.SetLength(strlen(cWriteData));
}
objFile.Close();
~ganesh