Re[2]: Deleting files problem

> Then why can’t I delete this file, it is obviously not used by some

process. I’m running Windows 7 x64.

Perhaps it’s mapped ?

L.

Ladislav Zezula wrote:

> Then why can’t I delete this file, it is obviously not used by some
> process. I’m running Windows 7 x64.

Perhaps it’s mapped ?

L.

If it was mapped, then shouldn’t a handle be open on this file? I
checked with process explorer, no handles are opened on this file.

If we’re talking about a CreateFile() sort of HANDLE, you can close that while it’s mapped.

mm

hFile = CreateFile()
hMap = CreateFileMapping(hFile)
CloseHandle(hFile)
pvFile = MapViewOfFile(hMap)
CloseHandle(hMap);

==> pvFile still exists, so the file is mapped,
but no handles are open. And the file cannot be deleted.
Verified with FileTest.

L.

xxxxx@volny.cz wrote:

hFile = CreateFile()
hMap = CreateFileMapping(hFile)
CloseHandle(hFile)
pvFile = MapViewOfFile(hMap)
CloseHandle(hMap);

==> pvFile still exists, so the file is mapped,
but no handles are open. And the file cannot be deleted.
Verified with FileTest.

L.

Is there a way to check if a file is mapped?

My first instinct would be to reach for MmCanFileBeTruncated, but I’d want
to be 100% certain that the SOP wasn’t going to be torn down under my feet
because you’d then get very odd crashes.

Rod

“Marian” wrote in message news:xxxxx@ntfsd…
> xxxxx@volny.cz wrote:
>> hFile = CreateFile()
>> hMap = CreateFileMapping(hFile)
>> CloseHandle(hFile)
>> pvFile = MapViewOfFile(hMap)
>> CloseHandle(hMap);
>>
>> ==> pvFile still exists, so the file is mapped,
>> but no handles are open. And the file cannot be deleted.
>> Verified with FileTest.
>>
>> L.
>>
>>
> Is there a way to check if a file is mapped?
>

> Is there a way to check if a file is mapped?

The FS can by consulting the Mm, see fastfat!FatSetDispositionInfo:

//
// Make sure there is no process mapping this file as an image.
//

if (!MmFlushImageSection( &Fcb->NonPaged->SectionObjectPointers,
MmFlushForDelete )) {

DebugTrace(-1, Dbg, “Cannot delete user mapped image\n”, 0);

return STATUS_CANNOT_DELETE;
}

This wouldn’t be something that you could safely do from an arbitrary filter
though.

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Marian” wrote in message news:xxxxx@ntfsd…
> xxxxx@volny.cz wrote:
>> hFile = CreateFile()
>> hMap = CreateFileMapping(hFile)
>> CloseHandle(hFile)
>> pvFile = MapViewOfFile(hMap)
>> CloseHandle(hMap);
>>
>> ==> pvFile still exists, so the file is mapped,
>> but no handles are open. And the file cannot be deleted.
>> Verified with FileTest.
>>
>> L.
>>
>>
> Is there a way to check if a file is mapped?
>

> If it was mapped, then shouldn’t a handle be open on this file?

Not necessary. It is possible to map the file and then close the handle, the mapping will survive.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Marian
The file you’re trying to delete is hardlink’ed with \windows\syswow64\ntdll.dll, which is in use. May be someone can explain to me why one cannot remove such hardlinks.

Maxim
“Windows File Protection” is indeed gone; “Windows Resource Protection” refers to the ACL set you mentioned.

Just curious, why we can’t do it safely?

Scott Noone wrote:

This wouldn’t be something that you could safely do from an arbitrary
filter though.

Your filter doesn’t maintain the structures involved here, the file system
does. So you’d need to coordinate your access with the file system’s (not to
say that it’s impossible, but you’re in waters that you probably don’t want
to be in at that point).

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Rajesh Gupta” wrote in message news:xxxxx@ntfsd…
> Just curious, why we can’t do it safely?
>
> Scott Noone wrote:
>
>> This wouldn’t be something that you could safely do from an arbitrary
>> filter though.
>

I’m pretty sure I’ve posted into this thread already - strangely my reply disappeared. Well, whatever - I’ll repost.

Maxim,
Windows File Protection is indeed gone; Windows Resource Protection refers to the ACL set you mentioned.

Marian,
The file you’re trying to delete is hardlinked with \windows\syswow64\ntdll.dll, which is in use. For some reason it’s impossible to remove one of the hardlinks in such cases (or may be there’s a way about which I don’t know?).

You’re reply posted, or at least I saw (and still see) it.

Maybe some filtering somewhere?

mm