In my mini-filter driver, I am trying to add some stuff after set the new file end. so I called the FltWriteFile to write from new end. The function always return 0xC0000128L. It should be STATUS_FILE_CLOSED.
I am confused. The completion of set info will cause the file object to be closed??? It seems okay in the set new allocation situation.
FLTFL_IO_OPERATION_NON_CACHED is NOT set in the function call since manual says it requires alignment to sector.
Can you please advise what happened here? thanks!
//
// MessageId: STATUS_FILE_CLOSED
//
// MessageText:
//
// An I/O request other than close and several other special case operations was attempted using a file object that had already been closed.
//
#define STATUS_FILE_CLOSED ((NTSTATUS)0xC0000128L)
A bit more info: I set FLT_PREOP_SYNCHRONIZE as return value in the pre-set info callback. Just according to the comments of swap-buffer sample.
The help information says it all (or most of it): you are trying to do an
application write after the file has been “closed”. By “closed” it means
that the handle has been closed (which means in FS tersms that an
IRP_MJ_CLEANUP has been sent).
The most likely set info you will get after a cleanup will have AdvanceOnly
set. But you can also be called in post operation after the cleanup has
completed even if the operation itself completed before the cleanup.
Is it possible caused by the file object is not operated in the original process context?
No. File objects are valid in any process context.
What is more likely is, as Rod suggests, you are trying to perform I/O
after the file has been cleaned up. Only paging I/O operations are
allowed between cleanup and close.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@sina.com
Sent: Friday, June 29, 2007 4:55 AM
To: ntfsd redirect
Subject: RE:[ntfsd] FltWriteFile return STATUS_FILE_CLOSED in post set
info callback
Is it possible caused by the file object is not operated in the original
process context?
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Tony,
I just observed when the FltWriteFile failed in post set info callback, the process id is 4. It should be a system process. I was testing with a notepad, so i guess the set info operation may be initiated by ccmanager or lazy write thread.
When the process id is the notepad process, the function always succeed.
It looks related with process cotext. However if it is lazy writer, probably the file object was already closed by notepad.
I used following codes to print the process id:
DebugTrace( DEBUG_TRACE_ALL_TRACKED_IO|DEBUG_TRACE_INFO,
“PreSetInfo: <%wZ> Enter (Cbd = %p, FO = %p, pid=%p, curpid=%p)\n”,
&context->FileName,
Cbd,
FltObjects->FileObject,
PsGetProcessId(IoThreadToProcess( Cbd->Thread)),
PsGetProcessId(IoGetCurrentProcess())) );
And I noticed the same statement can not print anything if the process id is displayed as 4 in pre-set info callback.
Thanks,
Wilson
> so i guess the set info operation may be initiated by ccmanager or lazy
write thread.
Almost certainly, but you could check the stack…
It looks related with process cotext. However if it is lazy writer,
probably the file object was already closed by notepad.
Yup.
I used following codes to print the process id:
DebugTrace( DEBUG_TRACE_ALL_TRACKED_IO|DEBUG_TRACE_INFO,
“PreSetInfo: <%wZ> Enter (Cbd = %p, FO = %p, pid=%p, curpid=%p)\n”,
&context->FileName,
Cbd,
FltObjects->FileObject,
PsGetProcessId(IoThreadToProcess( Cbd->Thread)),
PsGetProcessId(IoGetCurrentProcess())) );
And I noticed the same statement can not print anything if the process id
is displayed as 4 in pre-set info callback.
That’s usually because the formatting failed.
Why not set a breakpoint on the failure and take a look around. I’d be
pretty sure that most of the time its a set length with the AdvanceOnly bit
set. However as I said earlier you will (eventually) get called here in
other situations.