IFS close issue

NTFSD
1

I’m a newb debugging my first IFS network redirector and have an issue with the IRP_MJ_CLOSE synchronization. The driver is integrated with the cache manager, so I’m wondering if the following is a consequence of cache manager integration or if I have some other issue. When a user app writes a file I see the following sequence:

IRP_MJ_CREATE
IRP_MJ_READ
IRP_MJ_WRITE
IRP_MJ_CLOSE
IRP_MJ_CLEANUP
IRP_MJ_WRITE

I’m assuming there is something wrong with the driver as I expect the CLOSE to occur after all write activity has been completed. My original assumption was this behavior was caused by the cache manager, but I’m curious if anyone else has seen this sort of issue or if there may be some obvious explanation

Thanks.

2

You haven’t waited long enough. The close will come when the ref count
on the file object drops to zero.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

3

Hey Tony,

I think the OP is actually complaining that he’s seeing close before cleanup
and write, indicating he is not properly distinguishing between different
file objects.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Monday, February 12, 2007 11:17 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] IFS close issue

You haven’t waited long enough. The close will come when the ref count on
the file object drops to zero.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

The dispather looks like:

NTSTATUS DispatchIrp(
IN DEVICE_OBJECT pDeviceObject,
IN PIRP pIrp
)
{

IRP_CONTEXT pIrpContext = NULL;

pIrpContext = AllocateIrpContext(pDeviceObject, pIrp);

if (pIrpContext == NULL)
{
CompleteRequest(pIrp, STATUS_INSUFFICIENT_RESOURCES, 0);
return STATUS_INSUFFICIENT_RESOURCES;
}

return DispatchRequest(pIrpContext);

}

Where,

NTSTATUS DispatchRequest(
IN PIRP_CONTEXT pIrpContext
)
{

ASSERT(pIrpContext != NULL);

switch (pIrpContext->MajorFunction)
{
case IRP_MJ_CREATE:
return Create(pIrpContext);
case IRP_MJ_CLEANUP:
return Cleanup(pIrpContext);
case IRP_MJ_CLOSE:
return Close(pIrpContext);
case IRP_MJ_QUERY_INFORMATION:
return QueryInformation(pIrpContext);
case IRP_MJ_DIRECTORY_CONTROL:
return DirectoryControl(pIrpContext);
case IRP_MJ_QUERY_VOLUME_INFORMATION:
return QueryVolumeInformation(pIrpContext);
case IRP_MJ_READ:
return Read(pIrpContext);
case IRP_MJ_WRITE:
return Write(pIrpContext);
case IRP_MJ_SET_INFORMATION:
…
default:
CompleteIrpContext(pIrpContext, STATUS_NOT_IMPLEMENTED, 0);
return STATUS_NOT_IMPLEMENTED;
}

}

In this case I see IRP_MJ_CLOSE after the first or second write followed by another write(s). The Close() routine passes the close request to a service and returns. I’m not currently performing a check for the ReferenceCount dropping to 0 because I didn’t think I’d get a IRP_MJ_CLOSE unless the writes were already completed. Dan are you saying the CLOSE shouldn’t be seen until the writes are done (I only see the one)? Should I re-queue the request?

5

I’m saying the close is on a different FileObject then the subsequent
cleanup and write. Since IRP_MJ_CLOSE means deleting the FileObject, i.e.
freeing the memory for it, this must be the case.

Do some reading in the archives about stream file objects.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@comcast.net
Sent: Monday, February 12, 2007 2:31 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] IFS close issue

The dispather looks like:

NTSTATUS DispatchIrp(
IN DEVICE_OBJECT pDeviceObject,
IN PIRP pIrp
)
{

IRP_CONTEXT pIrpContext = NULL;

pIrpContext = AllocateIrpContext(pDeviceObject, pIrp);

if (pIrpContext == NULL)
{
CompleteRequest(pIrp, STATUS_INSUFFICIENT_RESOURCES, 0);
return STATUS_INSUFFICIENT_RESOURCES;
}

return DispatchRequest(pIrpContext);

}

Where,

NTSTATUS DispatchRequest(
IN PIRP_CONTEXT pIrpContext
)
{

ASSERT(pIrpContext != NULL);

switch (pIrpContext->MajorFunction)
{
case IRP_MJ_CREATE:
return Create(pIrpContext);
case IRP_MJ_CLEANUP:
return Cleanup(pIrpContext);
case IRP_MJ_CLOSE:
return Close(pIrpContext);
case IRP_MJ_QUERY_INFORMATION:
return QueryInformation(pIrpContext);
case IRP_MJ_DIRECTORY_CONTROL:
return DirectoryControl(pIrpContext);
case IRP_MJ_QUERY_VOLUME_INFORMATION:
return QueryVolumeInformation(pIrpContext);
case IRP_MJ_READ:
return Read(pIrpContext);
case IRP_MJ_WRITE:
return Write(pIrpContext);
case IRP_MJ_SET_INFORMATION:
…
default:
CompleteIrpContext(pIrpContext, STATUS_NOT_IMPLEMENTED, 0);
return STATUS_NOT_IMPLEMENTED;
}

}

In this case I see IRP_MJ_CLOSE after the first or second write followed by
another write(s). The Close() routine passes the close request to a service
and returns. I’m not currently performing a check for the ReferenceCount
dropping to 0 because I didn’t think I’d get a IRP_MJ_CLOSE unless the
writes were already completed. Dan are you saying the CLOSE shouldn’t be
seen until the writes are done (I only see the one)? Should I re-queue the
request?

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com