Hello!
I write filesystem minifilter for backup coping files,but when I recieve IRP_MJ_CREATE for file I’m don’t recieve IRP_MJ_CLOSE and sometimes IRP_MJ_CLEANUP…
How I can in minifilter catch moment when file copying is ended?
Well first there is a separate group NTFSD for file system questions.
Second, when you say you don’t receive, what do you mean. If you mean
“I did a copy and I did not immediately see a close” then your design
assumptions are wrong it can take a long time for the close to occur.
If you mean “I did a copy and waited a few days and did not see a close”
then your code is wrong.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Hello!
>
> I write filesystem minifilter for backup coping files,but when I recieve IRP_MJ_CREATE for file I’m don’t recieve IRP_MJ_CLOSE and sometimes IRP_MJ_CLEANUP…
>
> How I can in minifilter catch moment when file copying is ended?
Don Burn,sorry but I don’t know how to move my subject…
I mean “I did a copy and I did not immediately see a close” - at the moment of shutdown OS number of IRP_MJ_CLOSE != number of IRP_MJ_CREATE…
Start all over again to the ntfsd list.
The IRP_MJ_CLOSE can be delayed.
There can be more IRP_MJ_CLOSES than IRP_MJ_CREATEs.
Bill Wandel
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, July 19, 2012 4:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] FileSystem minifilter
Don Burn,sorry but I don’t know how to move my subject…
I mean “I did a copy and I did not immediately see a close” - at the moment
of shutdown OS number of IRP_MJ_CLOSE != number of IRP_MJ_CREATE…
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
> Well first there is a separate group NTFSD for file system questions.
Second, when you say you don’t receive, what do you mean. If you mean
“I did a copy and I did not immediately see a close” then your design
assumptions are wrong it can take a long time for the close to occur.
If you mean “I did a copy and waited a few days and did not see a close”
then your code is wrong.
Note that one way this can occur is if there are uncompleted IRPs still
active. The I/O Manager will not send a IRP_MJ_CLOSE until it has
received completions on all the IRPs it has sent. This means there must
never be an execution path that does not do what I term “graceful
recovery”. For example
status = SomeDDICall(…parameters…);
if(!NT_SUCCESS(status))
return STATUS_INSUFFICIENT_RESOURCES;
is the canonical code sample. Bad switch statements for DeviceIoControl
decoding are another.
It doesn’t take a few days to detect this; after about 5 minutes the I/O
Manager returns FALSE to CloseHandle (many people don’t notice that
CloseHandle is a BOOL). However, the driver will never get a Close IRP.
joe
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr“xxxxx@gmail.com” wrote in message
> news:xxxxx@ntdev:
>
>> Hello!
>>
>> I write filesystem minifilter for backup coping files,but when I recieve
>> IRP_MJ_CREATE for file I’m don’t recieve IRP_MJ_CLOSE and sometimes
>> IRP_MJ_CLEANUP…
>>
>> How I can in minifilter catch moment when file copying is ended?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Ok,but how I can know in minifilter about end of file copying?
wrote in message news:…
> It doesn’t take a few days to detect this; after about 5 minutes the I/O
> Manager returns FALSE to CloseHandle (many people don’t notice that
> CloseHandle is a BOOL). However, the driver will never get a Close IRP.
That’s a bug (that Driver Verifier should hopefully catch). The OP is
speaking specifically to a behavior they are seeing in a file system filter,
where not seeing a close for days/weeks/months/years (though I must admit
I’ve never waited years) is possible under normal conditions. The dangling
reference there is usually from Cc/Mm for caching purposes. In that case you
won’t see a close to the file object until memory pressure dictates or the
file system forcibly attempts to purge the data from memory (e.g. during
delete processing).
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
> Well first there is a separate group NTFSD for file system questions.
> Second, when you say you don’t receive, what do you mean. If you mean
> “I did a copy and I did not immediately see a close” then your design
> assumptions are wrong it can take a long time for the close to occur.
> If you mean “I did a copy and waited a few days and did not see a close”
> then your code is wrong.
Note that one way this can occur is if there are uncompleted IRPs still
active. The I/O Manager will not send a IRP_MJ_CLOSE until it has
received completions on all the IRPs it has sent. This means there must
never be an execution path that does not do what I term “graceful
recovery”. For example
status = SomeDDICall(…parameters…);
if(!NT_SUCCESS(status))
return STATUS_INSUFFICIENT_RESOURCES;
is the canonical code sample. Bad switch statements for DeviceIoControl
decoding are another.
It doesn’t take a few days to detect this; after about 5 minutes the I/O
Manager returns FALSE to CloseHandle (many people don’t notice that
CloseHandle is a BOOL). However, the driver will never get a Close IRP.
joe
>
>
> Don Burn
> Windows Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
>
>
>
>
> “xxxxx@gmail.com” wrote in message
> news:xxxxx@ntdev:
>
>> Hello!
>>
>> I write filesystem minifilter for backup coping files,but when I recieve
>> IRP_MJ_CREATE for file I’m don’t recieve IRP_MJ_CLOSE and sometimes
>> IRP_MJ_CLEANUP…
>>
>> How I can in minifilter catch moment when file copying is ended?
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Google:
detect file copy site:osronline.com
And start reading. We’ve discussed this a zillion times. Also, as previously
mentioned, this is a question for NTFSD and not NTDEV (though do NOT just
post this question to NTFSD without first doing your homework).
-scott
–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntdev…
Ok,but how I can know in minifilter about end of file copying?
>don’t recieve IRP_MJ_CLOSE
You will not see MJ_CLOSE till Cc’s garbage collector will decide to destroy the cache map for this file, which can take hours.
MJ_CLEANUP should be observed rather soon though.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com