File Caching in IRP_MJ_CREATE

Hi,

I am writing a filter driver for NT4.0 and am having trouble when filtering
IRP_MJ_CREATE requests. I think the problem is related file caching but
I’ve no idea how to solve the problem.

If I use the following code the open fails with access denied. I can see
that the IRP_MJ_CLOSE that I was expecting when I call ZwClose isn’t
received until after the function exits.(even though I am asking for
FILE_NO_INTERMEDIATE_BUFFERING and SYNCHRONIZE).

If I set file sharing options to FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE in my ZwCreate call. I can open the file but run into a
different problem. If someone is trys to delete a file, the delete call
seems to work but the file is left in a STATUS_DELETE_PENDING state. Again
I think it is waiting for a IRP_MJ_CLOSE.

Any enlightenment or work around would be greatly appreciated.

Thanks,
Mark.

The code follows:

NTSTATUS MyHookCreate(PDEVICE_OBJECT pDeviceObject, PIRP pIrp)
{
NTSTATUS ntStatus;
OBJECT_ATTRIBUTES ObjectAttributes;
IO_STATUS_BLOCK IoStatus;
PIO_STACK_LOCATION pCurrentStackLocation = NULL;
PIO_STACK_LOCATION pNextIoStackLocation = NULL;
PFILE_OBJECT pFileObject = NULL;
PHOOK_EXTENSION pDeviceExtension = NULL;
HANDLE hFile;
UNICODE_STRING ustrFullDevicePathName;

// Get basic information
pCurrentStackLocation = IoGetCurrentIrpStackLocation(pIrp);
pNextIoStackLocation = IoGetNextIrpStackLocation(pIrp);
pFileObject = pCurrentStackLocation->FileObject;
pDeviceExtension = pDeviceObject->DeviceExtension;

//Get the full device path file name from
//file object(ie. “\??\c:\temp\test.txt”)
GetFullDevicePathName(&ustrFullDevicePathName);

InitializeObjectAttributes (&ObjectAttributes, &ustrFullDevicePathName,
OBJ_CASE_INSENSITIVE,NULL,NULL);
ntStatus = ZwCreateFile(&hFile, GENERIC_READ | SYNCHRONIZE,
&ObjectAttributes, &IoStatus,NULL, 0, 0, FILE_OPEN,
FILE_NO_INTERMEDIATE_BUFFERING | FILE_NON_DIRECTORY_FILE |
FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0);
if(NT_SUCCESS(ntStatus))
{
ZwClose(&hFile);
}

// Copy parameters down to next level in the stack for the driver below us
*pNextIoStackLocation = *pCurrentStackLocation;
IoSetCompletionRoutine(pIrp, DefaultDispatchCompletion, NULL,
TRUE, TRUE, TRUE );
// Return the results of the call to the caller
return IoCallDriver(pDeviceExtension->FileSystem, pIrp);
}


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> If I use the following code the open fails with access denied. I can see

Do not call ZwCreateFile from CREATE filter.
Instead:

  • patch the original IRP and the name in the file object
  • pass it down
  • wait for it
  • after your work with the file is finished, call IoCancelFileOpen
  • the restore the IRP fields and the name in the file object and pass the IRP down without waiting to process the requested file
    open

Max


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thanks Max,

It works like a charm…

If I use the following code the open fails with access denied. I can see
Do not call ZwCreateFile from CREATE filter.
Instead:

  • patch the original IRP and the name in the file object
  • pass it down
  • wait for it
  • after your work with the file is finished, call IoCancelFileOpen
  • the restore the IRP fields and the name in the file object and pass the >IRP down without waiting to process the requested file
    open

Max


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you
do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because I/O
remembers that the count was already decremented via IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

If I use the following code the open fails with access denied. I can
see Do not call ZwCreateFile from CREATE filter.
Instead:

  • patch the original IRP and the name in the file object
  • pass it down
  • wait for it
  • after your work with the file is finished, call IoCancelFileOpen
  • the restore the IRP fields and the name in the file object and pass
    the >IRP down without waiting to process the requested file open

Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The following link is a link to a message from the NTFSD archives
contains an IoCancelFileOpen() decompilation by Jamey Kirby. I can’t
vouch for the validity of the disassembly (never having used it myself)
but it comes from Jamey, so I wouldn’t worry about using it.

http://www.osr.com/cgi-bin/lyris.pl?visit=ntfsd&id=171948642

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Monday, February 11, 2002 1:02 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you
do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because
I/O
remembers that the count was already decremented via
IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point
to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

> If I use the following code the open fails with access denied. I can
>see Do not call ZwCreateFile from CREATE filter.
>Instead:
>- patch the original IRP and the name in the file object
>- pass it down
>- wait for it
>- after your work with the file is finished, call IoCancelFileOpen
>- the restore the IRP fields and the name in the file object and pass
>the >IRP down without waiting to process the requested file open

>Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@secretseal.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

It is not clear just what is unsafe, can you clarify?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ravisankar
Pudipeddi
Sent: Monday, February 11, 2002 4:02 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you
do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because I/O
remembers that the count was already decremented via IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

If I use the following code the open fails with access denied. I can
see Do not call ZwCreateFile from CREATE filter.
Instead:

  • patch the original IRP and the name in the file object
  • pass it down
  • wait for it
  • after your work with the file is finished, call IoCancelFileOpen
  • the restore the IRP fields and the name in the file object and pass
    the >IRP down without waiting to process the requested file open

Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Poster says he did the following:
1.) Got a create IRP
2.) Changed file-name field in file object & sent it down to the
filesystem
3.) Wait in the filter for the create to complete
4.) Issued IoCancelFileOpen() on the now opened file
5.) Change the file-name in the file object back to the original.
6.) Send the create IRP down again to the file system.

Step 6) is unsafe - reusing the fileobject after cancelling the open. I
understand the poster ran into sharing violations - share access checks
can be bypassed via IoCreateFileSpecifyDeviceObjectHint().

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use
-----Original Message-----
From: Ken Galipeau [mailto:xxxxx@legato.com]
Sent: Monday, February 11, 2002 3:14 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

It is not clear just what is unsafe, can you clarify?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Ravisankar
Pudipeddi
Sent: Monday, February 11, 2002 4:02 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you
do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because I/O
remembers that the count was already decremented via IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

If I use the following code the open fails with access denied. I can
see Do not call ZwCreateFile from CREATE filter.
Instead:

  • patch the original IRP and the name in the file object
  • pass it down
  • wait for it
  • after your work with the file is finished, call IoCancelFileOpen
  • the restore the IRP fields and the name in the file object and pass
    the >IRP down without waiting to process the requested file open

Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The link did not work to bring up a specific message, however the code that
was published in the archive not too long ago does have a memory leak as the
IRPs are not freed.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nicholas Ryan
Sent: Monday, February 11, 2002 5:26 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

The following link is a link to a message from the NTFSD archives
contains an IoCancelFileOpen() decompilation by Jamey Kirby. I can’t
vouch for the validity of the disassembly (never having used it myself)
but it comes from Jamey, so I wouldn’t worry about using it.

http://www.osr.com/cgi-bin/lyris.pl?visit=ntfsd&id=171948642

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Monday, February 11, 2002 1:02 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you
do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because
I/O
remembers that the count was already decremented via
IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point
to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

> If I use the following code the open fails with access denied. I can
>see Do not call ZwCreateFile from CREATE filter.
>Instead:
>- patch the original IRP and the name in the file object
>- pass it down
>- wait for it
>- after your work with the file is finished, call IoCancelFileOpen
>- the restore the IRP fields and the name in the file object and pass
>the >IRP down without waiting to process the requested file open

>Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@secretseal.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

My code forgot to free an IRP; cut and paste issue when composing the
email. Easy enough to fix.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Galipeau
Sent: Monday, February 11, 2002 3:49 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

The link did not work to bring up a specific message, however the code
that was published in the archive not too long ago does have a memory
leak as the IRPs are not freed.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Nicholas Ryan
Sent: Monday, February 11, 2002 5:26 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

The following link is a link to a message from the NTFSD archives
contains an IoCancelFileOpen() decompilation by Jamey Kirby. I can’t
vouch for the validity of the disassembly (never having used it myself)
but it comes from Jamey, so I wouldn’t worry about using it.

http://www.osr.com/cgi-bin/lyris.pl?visit=ntfsd&id=171948642

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-ntfsd-
xxxxx@lists.osr.com] On Behalf Of Ravisankar Pudipeddi
Sent: Monday, February 11, 2002 1:02 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

This is unsafe.

The Vpb reference count goes out of whack when you do this.
IoCancelFileOpen() adjusts the Vpb count (i.e. decrements it) when you

do the IoCancelFileOpen(): now if the create that you send down the
second time fails for some reason, things will still be ok, because
I/O
remembers that the count was already decremented via
IoCancelFileOpen().

However if it succeeds, the count is now off by 1 (on the negative
side).

More importantly, it’s not safe to really touch the Vpb at this point
to
re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Ravi

This posting is provided “AS IS” with no warranties, and confers no
rights. You assume all risk for your use

-----Original Message-----
From: xxxxx@hotmail.com [mailto:xxxxx@hotmail.com]
Sent: Thursday, February 07, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] Re: File Caching in IRP_MJ_CREATE

Thanks Max,

It works like a charm…

> If I use the following code the open fails with access denied. I can

>see Do not call ZwCreateFile from CREATE filter.
>Instead:
>- patch the original IRP and the name in the file object
>- pass it down
>- wait for it
>- after your work with the file is finished, call IoCancelFileOpen
>- the restore the IRP fields and the name in the file object and pass

>the >IRP down without waiting to process the requested file open

>Max


You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com

To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@secretseal.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@legato.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

>More importantly, it’s not safe to really touch the Vpb at this point to

re-increment it back: it’s possible that after you called
IoCancelFileOpen(), the volume went away.

Maybe increment it before IoCancelFileOpen, and then decrement on successful CREATE?

Max


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com