Undeleteable files

NTFSD
1

The IrpTracker question I just posted is related to this issue. I have
a minifilter that restores offline files that have reparse points on
them. Unfortunately, once they’ve been restored, they can’t be deleted.
I’m working under the assumption that I’ve left something improperly
handled in the driver, and that’s causing the issue.

The file gets restored on a read or write to it, doing a create merely
caches some information that I need in the pre-operation callbacks for
read/write, a close drops that information from the cache. To test the
restore, I’m running copy [offlinefile] [somewhere], and it fails with
“Invalid Function”. Hence my suspicion that I’m handling something
incorrectly in the driver. I’m trying to use IrpTracker to hunt down
any Irps I might not be completing properly, but am having the
aforementioned problems. Are there other things I should be looking for
besides loose Irps hanging out? Running openfiles with local enabled
doesn’t turn up the undeleteable file. I’m guessing that means the
problems is somewhere pretty deep into things.

At this point, should I generate a crash dump and start trolling through
it with kd or windbg? If so, where can I find good documentation on
them, specifically relating to getting lists of Irps and File objects?
Is there any other route I should go down first to try to sort this
issue out?

Thanks,

~Eric

2

osr used to have a very nice document on parsing the FO and finding info
from it. ther are infact several papers on these things in OSR.

Also you may wish to try out filemon (as mentioned in your other thread),
also procmon.

are you sure there are no open references to the files, then delete will
fail. i am talking off the top of my hat here though…

On 9/12/07, Eric Diven wrote:
>
> The IrpTracker question I just posted is related to this issue. I have
> a minifilter that restores offline files that have reparse points on
> them. Unfortunately, once they’ve been restored, they can’t be deleted.
> I’m working under the assumption that I’ve left something improperly
> handled in the driver, and that’s causing the issue.
>
> The file gets restored on a read or write to it, doing a create merely
> caches some information that I need in the pre-operation callbacks for
> read/write, a close drops that information from the cache. To test the
> restore, I’m running copy [offlinefile] [somewhere], and it fails with
> “Invalid Function”. Hence my suspicion that I’m handling something
> incorrectly in the driver. I’m trying to use IrpTracker to hunt down
> any Irps I might not be completing properly, but am having the
> aforementioned problems. Are there other things I should be looking for
> besides loose Irps hanging out? Running openfiles with local enabled
> doesn’t turn up the undeleteable file. I’m guessing that means the
> problems is somewhere pretty deep into things.
>
> At this point, should I generate a crash dump and start trolling through
> it with kd or windbg? If so, where can I find good documentation on
> them, specifically relating to getting lists of Irps and File objects?
> Is there any other route I should go down first to try to sort this
> issue out?
>
> Thanks,
>
> ~Eric
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

–

- amitr0

3

You do not say if you remove the reparse point after recalling the file. If it is still there I would take a look at how you are handling the create request when the delete happens. It will be requesting delete access and you need to add FILE_OPEN_REPARSE_POINT to the options before passing it through. If you are not doing this the request will not succeed and the file cannot be deleted.

4

Important detail that, yes, we are taking off the reparse point when the
file gets restored. I can query that before and after the restore
happens, and it does get removed.

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, September 11, 2007 6:08 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Undeleteable files

You do not say if you remove the reparse point after recalling the file.
If it is still there I would take a look at how you are handling the
create request when the delete happens. It will be requesting delete
access and you need to add FILE_OPEN_REPARSE_POINT to the options before
passing it through. If you are not doing this the request will not
succeed and the file cannot be deleted.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

5

Okay, using Process Monitor and IrpTracker, I’ve seen that running del
path\file.jpg appears to succeed the first time it is run. On the
console, there is no output. The second time I run del path\file.jpg, I
get Access Denied on the console, and I see DELETE_PENDING in IrpTracker
or Process Monitor. Does this confirm my suspicion that I need to look
for a dangling Irp somewhere? Once again, openfiles doesn’t turn
anything up for the file in question, and the reparse point does
successfully get removed.

6

Check the fastfat source to see why you get this error code back. Basically,
the FCB for the file isn’t being torn down properly. Do you ever see a close
arrive for the file object used in the set information call?

You should try comparing the traces of a working delete to a delete of one
of your files to know what a successful case looks like. Forgetting to
complete an I/O operation probably isn’t your problem, it’s likely that
you’ve done something to reference the file object but never dropped the
reference.

Reference count issues, in a word, suck. If you can’t find anything obvious
through code inspection you mostly have two choices:

  1. Whittle your filter down to something that works then slowly start adding
    functionailty back until it breaks again

  2. Set an access breakpoint on the object’s reference count field and try to
    find the leak (this gets back to the whole “reference count issues suck”
    thing).

Others might have better ideas (or ideas more pertinent to your design).

Good luck!

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Eric Diven” wrote in message news:xxxxx@ntfsd…
Okay, using Process Monitor and IrpTracker, I’ve seen that running del
path\file.jpg appears to succeed the first time it is run. On the
console, there is no output. The second time I run del path\file.jpg, I
get Access Denied on the console, and I see DELETE_PENDING in IrpTracker
or Process Monitor. Does this confirm my suspicion that I need to look
for a dangling Irp somewhere? Once again, openfiles doesn’t turn
anything up for the file in question, and the reparse point does
successfully get removed.

7

Found the problem. The userland service opened a filehandle and never
closed it. Oops. I couldn’t see the offending open happen because I
was filtering IRPs that came through my driver, but the CreateFile was
being called with FILE_OPEN_REPARSE_POINT, which means it never hit my
PostCreate callback. There’s no PreCreate callback in it, and so it
slipped through. Live and learn. Procexp at least caught the unclosed
handle, then I just had to find it. Live and learn.

Thanks,

~Eric

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, September 12, 2007 2:44 PM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Undeleteable files

Check the fastfat source to see why you get this error code back.
Basically, the FCB for the file isn’t being torn down properly. Do you
ever see a close arrive for the file object used in the set information
call?

You should try comparing the traces of a working delete to a delete of
one of your files to know what a successful case looks like. Forgetting
to complete an I/O operation probably isn’t your problem, it’s likely
that you’ve done something to reference the file object but never
dropped the reference.

Reference count issues, in a word, suck. If you can’t find anything
obvious through code inspection you mostly have two choices:

  1. Whittle your filter down to something that works then slowly start
    adding functionailty back until it breaks again

  2. Set an access breakpoint on the object’s reference count field and
    try to find the leak (this gets back to the whole “reference count
    issues suck”
    thing).

Others might have better ideas (or ideas more pertinent to your design).

Good luck!

-scott

Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Eric Diven” wrote in message
news:xxxxx@ntfsd…
Okay, using Process Monitor and IrpTracker, I’ve seen that running del
path\file.jpg appears to succeed the first time it is run. On the
console, there is no output. The second time I run del path\file.jpg, I
get Access Denied on the console, and I see DELETE_PENDING in IrpTracker
or Process Monitor. Does this confirm my suspicion that I need to look
for a dangling Irp somewhere? Once again, openfiles doesn’t turn
anything up for the file in question, and the reparse point does
successfully get removed.

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new
fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@edsiohio.com To
unsubscribe send a blank email to xxxxx@lists.osr.com