Why an NTFS file can not be deleted but can be renamed?

NTFSD
1

I come across a weird problem:

A weird file “flashXXX.ocx” was created with FILE_OVERWRITE_IF on an NTFS volume. The file can be renamed within the same volume, but it cannot be deleted. I failed to delete it by some powerful deletion tools such as unlocker.exe, and these tools show that no process has the open handle to the file.

Even if I reboot the OS and enter the safe mode, the file still can not be deleted, but can be renamed.

Is this a bug of the NTFS file system driver?

2

What is the error on deletion? “Access Denied” or what?

wrote in message news:xxxxx@ntfsd…
>I come across a weird problem:
>
> A weird file “flashXXX.ocx” was created with FILE_OVERWRITE_IF on an NTFS volume. The file can be renamed within the same volume, but it cannot be deleted. I failed to delete it by some powerful deletion tools such as unlocker.exe, and these tools show that no process has the open handle to the file.
>
> Even if I reboot the OS and enter the safe mode, the file still can not be deleted, but can be renamed.
>
> Is this a bug of the NTFS file system driver?
>

3

@Maxim

The process monitor shows:

ZwCreateFile with DELETE|FILE_READ_DATA returns STATUS_SUCCESS

ZwCreateFile with DELETE|FILE_WRITE_DATA returns STATUS_ACCESS_DENIED

4

This typically happens when someone has the file mapped
(loaded DLL). Try that with any of the system DLLs (kernel32.dll).

Don’t forget to rename it back, or you will be unable to boot.

If it persists after reboot, I would suspect malicious behavior.

L.

5

>>Try that with any of the system DLLs (kernel32.dll).

>Don’t forget to rename it back, or you will be unable to boot.

I do not think there is a risk on new OSes; as OS will create the file from its cache as soon as one renames it.

@OP

There may not be any open handles to it, but references? For example some one might have done,

createfile,
createfilemapping,
mapviewoffile,
closehandle( mappingHandle),
closehandle( filehandle)

No unmapviewoffile call.

This will prevent delete as the file is still mapped.

6

Thanks, Aditya and Ladislav.

Your answers are very instructive to me. Though I have not tested what you pointed out, I have a new direction to investigate.

7

> createfile,

createfilemapping,
mapviewoffile,
closehandle( mappingHandle),
closehandle( filehandle)

No unmapviewoffile call.

In this case, you will have MJ_CLEANUP, but not MJ_CLOSE, and paging IO will still be occuring on a file.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

8

I think this is likely an ACL issue. Sounds like you have write permission
on the file but not delete. This is typically the case with files that
pertain to a (previous) Windows installation such as the users directory,
such files are very tough to delete. The process to delete them involves
removing inheritance, taking ownership of the file and then assigning
yourself the appropriate permissions to delete the file which is a tedious
process.

//Daniel

9

>>In this case, you will have MJ_CLEANUP, but not MJ_CLOSE, and paging IO will
still be occuring on a file.

Yes, but IO is happening or not does not affect the case described by OP. What matters is as there is no open handle, application which checks for open handles(as the one in OP) before deleting will not be able to delete the file.

Aditya