Close without IRQ_MJ_CLOSE

NTFSD
1

I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it possible for a
FILE_OBJECT to be closed without my filter driver seeing an IRP_MJ_CLOSE
(besides a higher level driver hijacking it)?

Thanks for any tips.

Neil

2

Are there any other file system filters loaded?

-----Original Message-----
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Tuesday, May 02, 2000 5:21 PM
To: File Systems Developers
Subject: [ntfsd] Close without IRQ_MJ_CLOSE

I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
possible for a
FILE_OBJECT to be closed without my filter driver seeing an
IRP_MJ_CLOSE
(besides a higher level driver hijacking it)?

Thanks for any tips.

Neil

You are currently subscribed to ntfsd as: xxxxx@nsisw.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

Thanks for the reply. I don’t believe there are other filter drivers.
However, I was asking more on a conceptual level: can a file be closed without
an IRP_MJ_CLOSE? (Since there is no FastIoClose.)

Subject: RE: Close without IRQ_MJ_CLOSE
From: Rob Fuller
Date: Tue, 2 May 2000 17:50:18 -0500
X-Message-Number: 17

Are there any other file system filters loaded?

> -----Original Message-----
> From: Neil Weicher [mailto:xxxxx@netlib.com]
> Sent: Tuesday, May 02, 2000 5:21 PM
> To: File Systems Developers
> Subject: [ntfsd] Close without IRQ_MJ_CLOSE
>
>
> I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
> IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> possible for a
> FILE_OBJECT to be closed without my filter driver seeing an
> IRP_MJ_CLOSE
> (besides a higher level driver hijacking it)?
>
> Thanks for any tips.

4

This subject has been discussed here before.
The problem is that you may not see CLOSEs after
much time before CLEANUP takes place. This is because
cache manager keeps a handle for your file for some time and
the CLOSE only takes place when cache manager releases this
reference.

Actually, many CLOSEs cannot be seen until the system shuts down.

Regards.
Inaki.

-----Original Message-----
From: Neil Weicher
Sent: mi?rcoles 3 de mayo de 2000 13:39
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Thanks for the reply. I don’t believe there are other filter drivers.
However, I was asking more on a conceptual level: can a file be closed
without
an IRP_MJ_CLOSE? (Since there is no FastIoClose.)

Subject: RE: Close without IRQ_MJ_CLOSE
From: Rob Fuller
> Date: Tue, 2 May 2000 17:50:18 -0500
> X-Message-Number: 17
>
> Are there any other file system filters loaded?
>
> > -----Original Message-----
> > From: Neil Weicher [mailto:xxxxx@netlib.com]
> > Sent: Tuesday, May 02, 2000 5:21 PM
> > To: File Systems Developers
> > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
> >
> >
> > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
> > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> > possible for a
> > FILE_OBJECT to be closed without my filter driver seeing an
> > IRP_MJ_CLOSE
> > (besides a higher level driver hijacking it)?
> >
> > Thanks for any tips.
>
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

5

Yes, but I think Neil is seeing the file object being reused without having
seen a close.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Iñaki Castillo
Sent: Wednesday, May 03, 2000 7:59 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

This subject has been discussed here before.
The problem is that you may not see CLOSEs after
much time before CLEANUP takes place. This is because
cache manager keeps a handle for your file for some time and
the CLOSE only takes place when cache manager releases this
reference.

Actually, many CLOSEs cannot be seen until the system shuts down.

Regards.
Inaki.

> -----Original Message-----
> From: Neil Weicher
> Sent: miércoles 3 de mayo de 2000 13:39
> To: File Systems Developers
> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
> Thanks for the reply. I don’t believe there are other filter drivers.
> However, I was asking more on a conceptual level: can a file be closed
> without
> an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
> ______________________________
>
> Subject: RE: Close without IRQ_MJ_CLOSE
> From: Rob Fuller
> > Date: Tue, 2 May 2000 17:50:18 -0500
> > X-Message-Number: 17
> >
> > Are there any other file system filters loaded?
> >
> > > -----Original Message-----
> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
> > > Sent: Tuesday, May 02, 2000 5:21 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
> > >
> > >
> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> > > possible for a
> > > FILE_OBJECT to be closed without my filter driver seeing an
> > > IRP_MJ_CLOSE
> > > (besides a higher level driver hijacking it)?
> > >
> > > Thanks for any tips.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

6

Hmmm,
I remember that under some circumstances fileobjects may be deleted by
IOManager when closing handles that were
obtained by means of ObReferenceObjectByPointer.

I mean, getting a handle with ObReferenceObjectByPointer and then closing it

forces IOManager to delete file object, without previously closing it.

Anyone remembers something about this issue ?

?:frowning:

-----Original Message-----
From: Jamey Kirby
Sent: mi?rcoles 3 de mayo de 2000 17:33
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Yes, but I think Neil is seeing the file object being reused without
having
seen a close.

Jamey

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of I?aki Castillo
> Sent: Wednesday, May 03, 2000 7:59 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
> This subject has been discussed here before.
> The problem is that you may not see CLOSEs after
> much time before CLEANUP takes place. This is because
> cache manager keeps a handle for your file for some time and
> the CLOSE only takes place when cache manager releases this
> reference.
>
> Actually, many CLOSEs cannot be seen until the system shuts down.
>
> Regards.
> Inaki.
>
>
> > -----Original Message-----
> > From: Neil Weicher
> > Sent: mi?rcoles 3 de mayo de 2000 13:39
> > To: File Systems Developers
> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
> >
> > Thanks for the reply. I don’t believe there are other filter drivers.
> > However, I was asking more on a conceptual level: can a file be closed
> > without
> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
> > ______________________________
> >
> > Subject: RE: Close without IRQ_MJ_CLOSE
> > From: Rob Fuller
> > > Date: Tue, 2 May 2000 17:50:18 -0500
> > > X-Message-Number: 17
> > >
> > > Are there any other file system filters loaded?
> > >
> > > > -----Original Message-----
> > > > From: Neil Weicher [mailto:xxxxx@netlib.com]
> > > > Sent: Tuesday, May 02, 2000 5:21 PM
> > > > To: File Systems Developers
> > > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
> > > >
> > > >
> > > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw
> an
> > > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> > > > possible for a
> > > > FILE_OBJECT to be closed without my filter driver seeing an
> > > > IRP_MJ_CLOSE
> > > > (besides a higher level driver hijacking it)?
> > > >
> > > > Thanks for any tips.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> > > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

7

File Object cannot be reused without sending IRP_MJ_CLOSE to a driver (File
System Driver if File Object represent a file). IRP_MJ_CLOSE is sended from
ObDereferenceObject (if reference count is zero and dereferenced object is
File Object). ObDereferenceObject is only way to free unused objects.

There may be following problems:
A) Some file system filtering drivers call directly file system driver to
avoid some conflicts. If your driver is layered between such a driver and
file system driver you cannot see some I/O.
B) NT Server caches open operations (it doesn’t close a file but wait for
another open request) so that you cannot see IRP_MJ_CLOSE and IRP_MJ_CLEANUP
requests for a long time. But this is not case of object reuse without
sending IRP_MJ_CLOSE.
C) There may be some special handling with removable media. It woud be
usefull to look at fast fat source.

Regards
mari

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, May 03, 2000 5:33 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Yes, but I think Neil is seeing the file object being reused without having
seen a close.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
Sent: Wednesday, May 03, 2000 7:59 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

This subject has been discussed here before.
The problem is that you may not see CLOSEs after
much time before CLEANUP takes place. This is because
cache manager keeps a handle for your file for some time and
the CLOSE only takes place when cache manager releases this
reference.

Actually, many CLOSEs cannot be seen until the system shuts down.

Regards.
Inaki.

> -----Original Message-----
> From: Neil Weicher
> Sent: miercoles 3 de mayo de 2000 13:39
> To: File Systems Developers
> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
> Thanks for the reply. I don’t believe there are other filter drivers.
> However, I was asking more on a conceptual level: can a file be closed
> without
> an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
> ______________________________
>
> Subject: RE: Close without IRQ_MJ_CLOSE
> From: Rob Fuller
> > Date: Tue, 2 May 2000 17:50:18 -0500
> > X-Message-Number: 17
> >
> > Are there any other file system filters loaded?
> >
> > > -----Original Message-----
> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
> > > Sent: Tuesday, May 02, 2000 5:21 PM
> > > To: File Systems Developers
> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
> > >
> > >
> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> > > possible for a
> > > FILE_OBJECT to be closed without my filter driver seeing an
> > > IRP_MJ_CLOSE
> > > (besides a higher level driver hijacking it)?
> > >
> > > Thanks for any tips.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>

—
You are currently subscribed to ntfsd as: xxxxx@decros.cz
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

8

> IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it possible for a

FILE_OBJECT to be closed without my filter driver seeing an IRP_MJ_CLOSE
(besides a higher level driver hijacking it)?

IRP_MJ_CLOSE is sent only when cache manager and memory decide to
get rid of all cache maps and section objects hanging off this file.
It can occur several hours later after closing a file.

Max

9

I think that the answer is easier than that: the file in question is opened
several times, i.e., there
are several handles(say two) for the same file stream. Fo each handle there
is a file object.
When one of these handles is closed (by means of CloseHandle) a CLEANUP is
requested. So IOManager, after CLEANUP, can free the fileobject being
closed. Then a new
CreateFile comes for the same file stream. IOManager can reuse this time the
same
file object. Only when all handles are closed a CLOSE request will be sent.

The question is that file object represent handles not files (file streams).

Inaki.

At 08:31 04/05/00 +0200, you wrote:

File Object cannot be reused without sending IRP_MJ_CLOSE to a driver (File
System Driver if File Object represent a file). IRP_MJ_CLOSE is sended from
ObDereferenceObject (if reference count is zero and dereferenced object is
File Object). ObDereferenceObject is only way to free unused objects.

There may be following problems:
A) Some file system filtering drivers call directly file system driver to
avoid some conflicts. If your driver is layered between such a driver and
file system driver you cannot see some I/O.
B) NT Server caches open operations (it doesn’t close a file but wait for
another open request) so that you cannot see IRP_MJ_CLOSE and IRP_MJ_CLEANUP
requests for a long time. But this is not case of object reuse without
sending IRP_MJ_CLOSE.
C) There may be some special handling with removable media. It woud be
usefull to look at fast fat source.

Regards
mari

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, May 03, 2000 5:33 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Yes, but I think Neil is seeing the file object being reused without having
seen a close.

Jamey

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
> Sent: Wednesday, May 03, 2000 7:59 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
> This subject has been discussed here before.
> The problem is that you may not see CLOSEs after
> much time before CLEANUP takes place. This is because
> cache manager keeps a handle for your file for some time and
> the CLOSE only takes place when cache manager releases this
> reference.
>
> Actually, many CLOSEs cannot be seen until the system shuts down.
>
> Regards.
> Inaki.
>
>
> > -----Original Message-----
> > From: Neil Weicher
> > Sent: miercoles 3 de mayo de 2000 13:39
> > To: File Systems Developers
> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
> >
> > Thanks for the reply. I don’t believe there are other filter drivers.
> > However, I was asking more on a conceptual level: can a file be closed
> > without
> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
> > ______________________________
> >
> > Subject: RE: Close without IRQ_MJ_CLOSE
> > From: Rob Fuller
>> > Date: Tue, 2 May 2000 17:50:18 -0500
>> > X-Message-Number: 17
>> >
>> > Are there any other file system filters loaded?
>> >
>> > > -----Original Message-----
>> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
>> > > Sent: Tuesday, May 02, 2000 5:21 PM
>> > > To: File Systems Developers
>> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
>> > >
>> > >
>> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw an
>> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
>> > > possible for a
>> > > FILE_OBJECT to be closed without my filter driver seeing an
>> > > IRP_MJ_CLOSE
>> > > (besides a higher level driver hijacking it)?
>> > >
>> > > Thanks for any tips.
>> >
>> >
>> >
>> >
>> > —
>> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
>> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>> —
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@decros.cz
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntfsd as: xxxxx@lander.es
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>

10

The close IRP is not delayed by handles to a file object, but by non-
handle references such as that representing the associated caching/
mapping section object. The cleanup IRP is the result of the last (user)
handle being closed. IO Manager cannot free a file-object after cleanup.
The FSD still has context data referenced through FsContext2, until the
close IRP. There must be a close IRP for every file object, not just
one for the file stream.

I’ve never heard of, or observed in practice, a create IRP being issued
on a file object that previously received cleanup but has not yet received
a close IRP. For the same file, yes, but not the same file *object*.

It’s documented that the OS does not parse the path provided in a
[Nt|Zw]CreateFile() call below the volume, so how would it find the FO
to re-create? Especially when related FOs may be gone, and FSDs may
replace the path string in an FO with the leaf name. No, NT just
allocates a new FO and passes it to the FSD so the FSD can parse the
path and find any existing FCB to link it to.

Other handles might be gotten via ObOpenObjectByPointer() but this won’t
result in a create IRP.

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Thursday, May 04, 2000 8:02 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

I think that the answer is easier than that: the file in question is opened
several times, i.e., there
are several handles(say two) for the same file stream. Fo each handle there
is a file object.
When one of these handles is closed (by means of CloseHandle) a CLEANUP is
requested. So IOManager, after CLEANUP, can free the fileobject being
closed. Then a new
CreateFile comes for the same file stream. IOManager can reuse this time the
same
file object. Only when all handles are closed a CLOSE request will be sent.

The question is that file object represent handles not files (file streams).

Inaki.

At 08:31 04/05/00 +0200, you wrote:

File Object cannot be reused without sending IRP_MJ_CLOSE to a driver (File
System Driver if File Object represent a file). IRP_MJ_CLOSE is sended from
ObDereferenceObject (if reference count is zero and dereferenced object is
File Object). ObDereferenceObject is only way to free unused objects.

There may be following problems:
A) Some file system filtering drivers call directly file system driver to
avoid some conflicts. If your driver is layered between such a driver and
file system driver you cannot see some I/O.
B) NT Server caches open operations (it doesn’t close a file but wait for
another open request) so that you cannot see IRP_MJ_CLOSE and
IRP_MJ_CLEANUP
requests for a long time. But this is not case of object reuse without
sending IRP_MJ_CLOSE.
C) There may be some special handling with removable media. It woud be
usefull to look at fast fat source.

Regards
mari

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Wednesday, May 03, 2000 5:33 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Yes, but I think Neil is seeing the file object being reused without having
seen a close.

Jamey

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
> Sent: Wednesday, May 03, 2000 7:59 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
> This subject has been discussed here before.
> The problem is that you may not see CLOSEs after
> much time before CLEANUP takes place. This is because
> cache manager keeps a handle for your file for some time and
> the CLOSE only takes place when cache manager releases this
> reference.
>
> Actually, many CLOSEs cannot be seen until the system shuts down.
>
> Regards.
> Inaki.
>
>
> > -----Original Message-----
> > From: Neil Weicher
> > Sent: miercoles 3 de mayo de 2000 13:39
> > To: File Systems Developers
> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
> >
> > Thanks for the reply. I don’t believe there are other filter drivers.
> > However, I was asking more on a conceptual level: can a file be closed
> > without
> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
> > ______________________________
> >
> > Subject: RE: Close without IRQ_MJ_CLOSE
> > From: Rob Fuller
>> > Date: Tue, 2 May 2000 17:50:18 -0500
>> > X-Message-Number: 17
>> >
>> > Are there any other file system filters loaded?
>> >
>> > > -----Original Message-----
>> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
>> > > Sent: Tuesday, May 02, 2000 5:21 PM
>> > > To: File Systems Developers
>> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
>> > >
>> > >
>> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw
an
>> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
>> > > possible for a
>> > > FILE_OBJECT to be closed without my filter driver seeing an
>> > > IRP_MJ_CLOSE
>> > > (besides a higher level driver hijacking it)?
>> > >
>> > > Thanks for any tips.
>> >
>> >
>> >
>> >
>> > —
>> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
>> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>> —
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@decros.cz
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntfsd as: xxxxx@lander.es
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>

—
You are currently subscribed to ntfsd as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

11

>The cleanup IRP is the result of the last (user)

handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

At 23:30 04/05/00 -0600, you wrote:

The close IRP is not delayed by handles to a file object, but by non-
handle references such as that representing the associated caching/
mapping section object. The cleanup IRP is the result of the last (user)
handle being closed. IO Manager cannot free a file-object after cleanup.
The FSD still has context data referenced through FsContext2, until the
close IRP. There must be a close IRP for every file object, not just
one for the file stream.

I’ve never heard of, or observed in practice, a create IRP being issued
on a file object that previously received cleanup but has not yet received
a close IRP. For the same file, yes, but not the same file *object*.

It’s documented that the OS does not parse the path provided in a
[Nt|Zw]CreateFile() call below the volume, so how would it find the FO
to re-create? Especially when related FOs may be gone, and FSDs may
replace the path string in an FO with the leaf name. No, NT just
allocates a new FO and passes it to the FSD so the FSD can parse the
path and find any existing FCB to link it to.

Other handles might be gotten via ObOpenObjectByPointer() but this won’t
result in a create IRP.

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Thursday, May 04, 2000 8:02 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

I think that the answer is easier than that: the file in question is opened
several times, i.e., there
are several handles(say two) for the same file stream. Fo each handle there
is a file object.
When one of these handles is closed (by means of CloseHandle) a CLEANUP is
requested. So IOManager, after CLEANUP, can free the fileobject being
closed. Then a new
CreateFile comes for the same file stream. IOManager can reuse this time the
same
file object. Only when all handles are closed a CLOSE request will be sent.

The question is that file object represent handles not files (file streams).

Inaki.

At 08:31 04/05/00 +0200, you wrote:
>File Object cannot be reused without sending IRP_MJ_CLOSE to a driver (File
>System Driver if File Object represent a file). IRP_MJ_CLOSE is sended from
>ObDereferenceObject (if reference count is zero and dereferenced object is
>File Object). ObDereferenceObject is only way to free unused objects.
>
>There may be following problems:
>A) Some file system filtering drivers call directly file system driver to
>avoid some conflicts. If your driver is layered between such a driver and
>file system driver you cannot see some I/O.
>B) NT Server caches open operations (it doesn’t close a file but wait for
>another open request) so that you cannot see IRP_MJ_CLOSE and
IRP_MJ_CLEANUP
>requests for a long time. But this is not case of object reuse without
>sending IRP_MJ_CLOSE.
>C) There may be some special handling with removable media. It woud be
>usefull to look at fast fat source.
>
>Regards
>mari
>
>
>-----Original Message-----
>From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
>Sent: Wednesday, May 03, 2000 5:33 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
>Yes, but I think Neil is seeing the file object being reused without having
>seen a close.
>
>Jamey
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
>> Sent: Wednesday, May 03, 2000 7:59 AM
>> To: File Systems Developers
>> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>>
>>
>> This subject has been discussed here before.
>> The problem is that you may not see CLOSEs after
>> much time before CLEANUP takes place. This is because
>> cache manager keeps a handle for your file for some time and
>> the CLOSE only takes place when cache manager releases this
>> reference.
>>
>> Actually, many CLOSEs cannot be seen until the system shuts down.
>>
>> Regards.
>> Inaki.
>>
>>
>> > -----Original Message-----
>> > From: Neil Weicher
>> > Sent: miercoles 3 de mayo de 2000 13:39
>> > To: File Systems Developers
>> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>> >
>> > Thanks for the reply. I don’t believe there are other filter drivers.
>> > However, I was asking more on a conceptual level: can a file be closed
>> > without
>> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
>> > ______________________________
>> >
>> > Subject: RE: Close without IRQ_MJ_CLOSE
>> > From: Rob Fuller
>>> > Date: Tue, 2 May 2000 17:50:18 -0500
>>> > X-Message-Number: 17
>>> >
>>> > Are there any other file system filters loaded?
>>> >
>>> > > -----Original Message-----
>>> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
>>> > > Sent: Tuesday, May 02, 2000 5:21 PM
>>> > > To: File Systems Developers
>>> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
>>> > >
>>> > >
>>> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw
>an
>>> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
>>> > > possible for a
>>> > > FILE_OBJECT to be closed without my filter driver seeing an
>>> > > IRP_MJ_CLOSE
>>> > > (besides a higher level driver hijacking it)?
>>> > >
>>> > > Thanks for any tips.
>>> >
>>> >
>>> >
>>> >
>>> > —
>>> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
>>> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>>
>>> —
>>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>>
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@decros.cz
>>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@lander.es
>>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>>
>>
>
>
>—
>You are currently subscribed to ntfsd as: david_cox2@hp.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntfsd as: xxxxx@lander.es
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>

12

Well, I meant, a CLEANUP for for each user file object. :frowning:

At 23:30 04/05/00 -0600, you wrote:

The close IRP is not delayed by handles to a file object, but by non-
handle references such as that representing the associated caching/
mapping section object. The cleanup IRP is the result of the last (user)
handle being closed. IO Manager cannot free a file-object after cleanup.
The FSD still has context data referenced through FsContext2, until the
close IRP. There must be a close IRP for every file object, not just
one for the file stream.

I’ve never heard of, or observed in practice, a create IRP being issued
on a file object that previously received cleanup but has not yet received
a close IRP. For the same file, yes, but not the same file *object*.

It’s documented that the OS does not parse the path provided in a
[Nt|Zw]CreateFile() call below the volume, so how would it find the FO
to re-create? Especially when related FOs may be gone, and FSDs may
replace the path string in an FO with the leaf name. No, NT just
allocates a new FO and passes it to the FSD so the FSD can parse the
path and find any existing FCB to link it to.

Other handles might be gotten via ObOpenObjectByPointer() but this won’t
result in a create IRP.

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Thursday, May 04, 2000 8:02 PM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

I think that the answer is easier than that: the file in question is opened
several times, i.e., there
are several handles(say two) for the same file stream. Fo each handle there
is a file object.
When one of these handles is closed (by means of CloseHandle) a CLEANUP is
requested. So IOManager, after CLEANUP, can free the fileobject being
closed. Then a new
CreateFile comes for the same file stream. IOManager can reuse this time the
same
file object. Only when all handles are closed a CLOSE request will be sent.

The question is that file object represent handles not files (file streams).

Inaki.

At 08:31 04/05/00 +0200, you wrote:
>File Object cannot be reused without sending IRP_MJ_CLOSE to a driver (File
>System Driver if File Object represent a file). IRP_MJ_CLOSE is sended from
>ObDereferenceObject (if reference count is zero and dereferenced object is
>File Object). ObDereferenceObject is only way to free unused objects.
>
>There may be following problems:
>A) Some file system filtering drivers call directly file system driver to
>avoid some conflicts. If your driver is layered between such a driver and
>file system driver you cannot see some I/O.
>B) NT Server caches open operations (it doesn’t close a file but wait for
>another open request) so that you cannot see IRP_MJ_CLOSE and
IRP_MJ_CLEANUP
>requests for a long time. But this is not case of object reuse without
>sending IRP_MJ_CLOSE.
>C) There may be some special handling with removable media. It woud be
>usefull to look at fast fat source.
>
>Regards
>mari
>
>
>-----Original Message-----
>From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
>Sent: Wednesday, May 03, 2000 5:33 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
>Yes, but I think Neil is seeing the file object being reused without having
>seen a close.
>
>Jamey
>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
>> Sent: Wednesday, May 03, 2000 7:59 AM
>> To: File Systems Developers
>> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>>
>>
>> This subject has been discussed here before.
>> The problem is that you may not see CLOSEs after
>> much time before CLEANUP takes place. This is because
>> cache manager keeps a handle for your file for some time and
>> the CLOSE only takes place when cache manager releases this
>> reference.
>>
>> Actually, many CLOSEs cannot be seen until the system shuts down.
>>
>> Regards.
>> Inaki.
>>
>>
>> > -----Original Message-----
>> > From: Neil Weicher
>> > Sent: miercoles 3 de mayo de 2000 13:39
>> > To: File Systems Developers
>> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>> >
>> > Thanks for the reply. I don’t believe there are other filter drivers.
>> > However, I was asking more on a conceptual level: can a file be closed
>> > without
>> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
>> > ______________________________
>> >
>> > Subject: RE: Close without IRQ_MJ_CLOSE
>> > From: Rob Fuller
>>> > Date: Tue, 2 May 2000 17:50:18 -0500
>>> > X-Message-Number: 17
>>> >
>>> > Are there any other file system filters loaded?
>>> >
>>> > > -----Original Message-----
>>> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
>>> > > Sent: Tuesday, May 02, 2000 5:21 PM
>>> > > To: File Systems Developers
>>> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
>>> > >
>>> > >
>>> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never saw
>an
>>> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
>>> > > possible for a
>>> > > FILE_OBJECT to be closed without my filter driver seeing an
>>> > > IRP_MJ_CLOSE
>>> > > (besides a higher level driver hijacking it)?
>>> > >
>>> > > Thanks for any tips.
>>> >
>>> >
>>> >
>>> >
>>> > —
>>> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
>>> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>>
>>> —
>>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>>> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>>
>>
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@decros.cz
>>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>>—
>>You are currently subscribed to ntfsd as: xxxxx@lander.es
>>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>>
>>
>>
>
>
>—
>You are currently subscribed to ntfsd as: david_cox2@hp.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntfsd as: xxxxx@lander.es
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
>

13
  1. And what you think will be done when the user obtains one hanlde
    by calling Nt(Zw)Create(Open)File and next two by Nt(Zw)DuplicateObject
    ?

I think you have bad informations about Object Manager.
If you want I can make the Object Manager more clear to all.

  1. Every file object is an instance of user file open. Thus there may be
    several file objects for one only file stream.
    When the last handle for every file object is closed, File system
    receives IRP_MJ_CLEANUP.
    Before every file object is deallocated the File system receives
    IRP_MJ_CLOSE.

Paul

-----P?vodn? zpr?va-----
Od: Inaki Castillo [SMTP:xxxxx@lander.es]
Odesl?no: 5. kv?tna 2000 16:02
Komu: File Systems Developers
P?edm?t: [ntfsd] RE: Close without IRQ_MJ_CLOSE

>The cleanup IRP is the result of the last (user)
>handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

At 23:30 04/05/00 -0600, you wrote:
>The close IRP is not delayed by handles to a file object, but by non-
>handle references such as that representing the associated caching/
>mapping section object. The cleanup IRP is the result of the last (user)
>handle being closed. IO Manager cannot free a file-object after cleanup.
>The FSD still has context data referenced through FsContext2, until the
>close IRP. There must be a close IRP for every file object, not just
>one for the file stream.
>
>I’ve never heard of, or observed in practice, a create IRP being issued
>on a file object that previously received cleanup but has not yet
received
>a close IRP. For the same file, yes, but not the same file *object*.
>
>It’s documented that the OS does not parse the path provided in a
>[Nt|Zw]CreateFile() call below the volume, so how would it find the FO
>to re-create? Especially when related FOs may be gone, and FSDs may
>replace the path string in an FO with the leaf name. No, NT just
>allocates a new FO and passes it to the FSD so the FSD can parse the
>path and find any existing FCB to link it to.
>
>Other handles might be gotten via ObOpenObjectByPointer() but this won’t
>result in a create IRP.
>
>-----------------------------------------------------------------------
>Dave Cox
>Hewlett-Packard Co.
>HPSO/SSMO (Santa Barbara)
>https://ecardfile.com/id/Dave+Cox
>
>
>-----Original Message-----
>From: Inaki Castillo [mailto:xxxxx@lander.es]
>Sent: Thursday, May 04, 2000 8:02 PM
>To: File Systems Developers
>Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>
>
>I think that the answer is easier than that: the file in question is
opened
>several times, i.e., there
>are several handles(say two) for the same file stream. Fo each handle
there
>is a file object.
>When one of these handles is closed (by means of CloseHandle) a CLEANUP
is
>requested. So IOManager, after CLEANUP, can free the fileobject being
>closed. Then a new
>CreateFile comes for the same file stream. IOManager can reuse this time
the
>same
>file object. Only when all handles are closed a CLOSE request will be
sent.
>
>The question is that file object represent handles not files (file
streams).
>
>Inaki.
>
>At 08:31 04/05/00 +0200, you wrote:
>>File Object cannot be reused without sending IRP_MJ_CLOSE to a driver
(File
>>System Driver if File Object represent a file). IRP_MJ_CLOSE is sended
from
>>ObDereferenceObject (if reference count is zero and dereferenced object
is
>>File Object). ObDereferenceObject is only way to free unused objects.
>>
>>There may be following problems:
>>A) Some file system filtering drivers call directly file system driver
to
>>avoid some conflicts. If your driver is layered between such a driver
and
>>file system driver you cannot see some I/O.
>>B) NT Server caches open operations (it doesn’t close a file but wait
for
>>another open request) so that you cannot see IRP_MJ_CLOSE and
>IRP_MJ_CLEANUP
>>requests for a long time. But this is not case of object reuse without
>>sending IRP_MJ_CLOSE.
>>C) There may be some special handling with removable media. It woud be
>>usefull to look at fast fat source.
>>
>>Regards
>>mari
>>
>>
>>-----Original Message-----
>>From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
>>Sent: Wednesday, May 03, 2000 5:33 PM
>>To: File Systems Developers
>>Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>>
>>
>>Yes, but I think Neil is seeing the file object being reused without
having
>>seen a close.
>>
>>Jamey
>>
>>> -----Original Message-----
>>> From: xxxxx@lists.osr.com
>>> [mailto:xxxxx@lists.osr.com]On Behalf Of Inaki Castillo
>>> Sent: Wednesday, May 03, 2000 7:59 AM
>>> To: File Systems Developers
>>> Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>>>
>>>
>>> This subject has been discussed here before.
>>> The problem is that you may not see CLOSEs after
>>> much time before CLEANUP takes place. This is because
>>> cache manager keeps a handle for your file for some time and
>>> the CLOSE only takes place when cache manager releases this
>>> reference.
>>>
>>> Actually, many CLOSEs cannot be seen until the system shuts down.
>>>
>>> Regards.
>>> Inaki.
>>>
>>>
>>> > -----Original Message-----
>>> > From: Neil Weicher
>>> > Sent: miercoles 3 de mayo de 2000 13:39
>>> > To: File Systems Developers
>>> > Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE
>>> >
>>> > Thanks for the reply. I don’t believe there are other filter
drivers.
>>> > However, I was asking more on a conceptual level: can a file be
closed
>>> > without
>>> > an IRP_MJ_CLOSE? (Since there is no FastIoClose.)
>>> > ______________________________
>>> >
>>> > Subject: RE: Close without IRQ_MJ_CLOSE
>>> > From: Rob Fuller
> >>> > Date: Tue, 2 May 2000 17:50:18 -0500
> >>> > X-Message-Number: 17
> >>> >
> >>> > Are there any other file system filters loaded?
> >>> >
> >>> > > -----Original Message-----
> >>> > > From: Neil Weicher [mailto:xxxxx@netlib.com]
> >>> > > Sent: Tuesday, May 02, 2000 5:21 PM
> >>> > > To: File Systems Developers
> >>> > > Subject: [ntfsd] Close without IRQ_MJ_CLOSE
> >>> > >
> >>> > >
> >>> > > I am receiving an IRQ_MJ_CREATE with a FILE_OBJECT that I never
> saw
> >an
> >>> > > IRP_MJ_CLOSE for (from an earlier IRP_MJ_CREATE). Is it
> >>> > > possible for a
> >>> > > FILE_OBJECT to be closed without my filter driver seeing an
> >>> > > IRP_MJ_CLOSE
> >>> > > (besides a higher level driver hijacking it)?
> >>> > >
> >>> > > Thanks for any tips.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > —
> >>> > You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es
> >>> > To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >>>
> >>> —
> >>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> >>> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >>>
> >>
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@decros.cz
> >>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >>
> >>—
> >>You are currently subscribed to ntfsd as: xxxxx@lander.es
> >>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >>
> >>
> >>
> >
> >
> >—
> >You are currently subscribed to ntfsd as: david_cox2@hp.com
> >To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> >—
> >You are currently subscribed to ntfsd as: xxxxx@lander.es
> >To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> >
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@sodatsw.cz
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)

14

Not quite.

Objects (an example: fileobjects) have two counts: a handle count and
pointer count. You can use the !object debugger extension to crack the
object header and see these.

pointer = handle + N

where N = the number of extra references (ObReferenceObject) placed on
the fileobject by kernel/system components. For a cached file, for
instance, you will typically see 1 handle count and 3 pointer count: the
handle, and a reference for each of the cache manager and memory manager
for the underlying cache setup.

The handle count indicates the number of entries in process handle
tables which refer to this precise object. Usually, of course, this is

  1. But you can duplicate a handle to that fileobject into other
    processes. This increments the handle count.

Cleanup happens when handle count reaches zero.

Close happens when pointer count reaches zero.

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Friday, May 05, 2000 7:02 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

The cleanup IRP is the result of the last (user)
handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

15

What would happen if a driver opened a file object, which has already
received IRP_MJ_CLEANUP, via ObOpenObjectByPointer()? Would it work?
When the returned handle is closed, what happens? Do the Ob/Io mgrs
recognize that the FO has already been cleaned-up and refrain from
issuing another cleanup IRP?

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Daniel Lovinger [mailto:xxxxx@Exchange.Microsoft.com]
Sent: Friday, May 05, 2000 9:40 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Not quite.

Objects (an example: fileobjects) have two counts: a handle count and
pointer count. You can use the !object debugger extension to crack the
object header and see these.

pointer = handle + N

where N = the number of extra references (ObReferenceObject) placed on the
fileobject by kernel/system components. For a cached file, for instance, you
will typically see 1 handle count and 3 pointer count: the handle, and a
reference for each of the cache manager and memory manager for the
underlying cache setup.

The handle count indicates the number of entries in process handle tables
which refer to this precise object. Usually, of course, this is 1. But you
can duplicate a handle to that fileobject into other processes. This
increments the handle count.

Cleanup happens when handle count reaches zero.

Close happens when pointer count reaches zero.

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Friday, May 05, 2000 7:02 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

The cleanup IRP is the result of the last (user)
handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

16

Really nice explanation.
Thanks!

Inaki.

At 09:40 05/05/00 -0700, you wrote:

Not quite.

Objects (an example: fileobjects) have two counts: a handle count and
pointer count. You can use the !object debugger extension to crack the
object header and see these.

pointer = handle + N

where N = the number of extra references (ObReferenceObject) placed on
the fileobject by kernel/system components. For a cached file, for
instance, you will typically see 1 handle count and 3 pointer count: the
handle, and a reference for each of the cache manager and memory manager
for the underlying cache setup.

The handle count indicates the number of entries in process handle
tables which refer to this precise object. Usually, of course, this is

  1. But you can duplicate a handle to that fileobject into other
    processes. This increments the handle count.

Cleanup happens when handle count reaches zero.

Close happens when pointer count reaches zero.

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Friday, May 05, 2000 7:02 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

>The cleanup IRP is the result of the last (user)
>handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

RE: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Not quite.

Objects (an example: fileobjects) have two counts: a handle
count and pointer count. You can use the !object debugger extension to crack
the object header and see these.

pointer = handle + N

where N = the number of extra references
(ObReferenceObject) placed on the fileobject by kernel/system components.
For a cached file, for instance, you will typically see 1 handle count and 3
pointer count: the handle, and a reference for each of the cache manager and
memory manager for the underlying cache setup.

The handle count indicates the number of entries in process
handle tables which refer to this precise object. Usually, of course, this
is 1. But you can duplicate a handle to that fileobject into other
processes. This increments the handle count.

Cleanup happens when handle count reaches zero.

Close happens when pointer count reaches zero.

-----Original Message-----

From: Inaki Castillo [HREF=“mailto:xxxxx@lander.es”>mailto:xxxxx@lander.es]

Sent: Friday, May 05, 2000 7:02 AM

To: File Systems Developers

Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

>The cleanup IRP is the result of the last (user)

>handle being closed.

Sorry but this is not true. CLEANUP comes for each
CloseHandle.

If user has three handles three CLEANUPs come.

17

I appreciate all explanations about this subject and I would like
to pose again a related question we posed time ago in an OSR seminar.

Imagine the following scenary: I had a filter driver, and in this filter I
filtered
several IRPs, say I am filtering CLEANUP.

Well, at CLEANUP I have a FileObject, but for certain purposes I needed
a handle (say to call an NT function).

To get a handle I used ObOpenObjectByPointer. Then with the handle I got
I did some calls to standard NT functions ant it worked nicely. So the
handle was a valid handle.

When I did not need anymore the handle I closed it with
CloseHandle. That seems right but actually an unexpected effect occurred:
the file object was ‘invalidated’. We traced some code and found that the
FileObject was actually deleted by IOManager unexpectedly, time after
closing the
handle. Note that it was invalidated even before CLEANUP function completed!.

Has this behaviour some explanation ?

Thanks.
Inaki.

At 13:02 05/05/00 -0600, you wrote:

What would happen if a driver opened a file object, which has already
received IRP_MJ_CLEANUP, via ObOpenObjectByPointer()? Would it work?
When the returned handle is closed, what happens? Do the Ob/Io mgrs
recognize that the FO has already been cleaned-up and refrain from
issuing another cleanup IRP?

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Daniel Lovinger [mailto:xxxxx@Exchange.Microsoft.com]
Sent: Friday, May 05, 2000 9:40 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

Not quite.

Objects (an example: fileobjects) have two counts: a handle count and
pointer count. You can use the !object debugger extension to crack the
object header and see these.

pointer = handle + N

where N = the number of extra references (ObReferenceObject) placed on the
fileobject by kernel/system components. For a cached file, for instance, you
will typically see 1 handle count and 3 pointer count: the handle, and a
reference for each of the cache manager and memory manager for the
underlying cache setup.

The handle count indicates the number of entries in process handle tables
which refer to this precise object. Usually, of course, this is 1. But you
can duplicate a handle to that fileobject into other processes. This
increments the handle count.

Cleanup happens when handle count reaches zero.

Close happens when pointer count reaches zero.

-----Original Message-----
From: Inaki Castillo [mailto:xxxxx@lander.es]
Sent: Friday, May 05, 2000 7:02 AM
To: File Systems Developers
Subject: [ntfsd] RE: Close without IRQ_MJ_CLOSE

>The cleanup IRP is the result of the last (user)
>handle being closed.

Sorry but this is not true. CLEANUP comes for each CloseHandle.
If user has three handles three CLEANUPs come.

You are currently subscribed to ntfsd as: xxxxx@lander.es
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

18

RE: [ntfsd] RE: Close without IRQ_MJ_CLOSE>Close happens when pointer count
reaches zero.

…and just before the object itself is freed by the OS. It is like a C++
destructor.

Max

19

> the file object was ‘invalidated’. We traced some code and found that the

FileObject was actually deleted by IOManager unexpectedly, time after
closing the
handle. Note that it was invalidated even before CLEANUP function
completed!.

Is CLEANUP function re-entered before object destruction?

Max