Deleteing files.. ACCESS_DENIED and CANNOT_DELETE errors.


I am probably missing something obvious, but so much of simple file I/O has been different in kernel mode, that it could be something bigger.

So I am trying to delete our “data cache” folder. These are our files, copies of some random files (a lot of them).
I am trying to delete those files, but for a few of them (like… 0.001%), I get STATUS_ACCESS_DENIED when I try to open them this way:

                                            &ObjAttr, // We may reuse ObjAttr, as it points to szPath, which
                                                      // now includes the component name.
                                            FILE_SHARE_READ | FILE_SHARE_WRITE,
The above code is used to try and remove a possible read-only flag, but it fails.

This is during InstanceSetup at boot. Files are definitely not open by anything,

Any clues?

Ah, I love these “spend 5 days without success bugs, post a query, find a solution right after you post.” :slight_smile:

I was asking for too many permissions, FILE_WRITE_ATTRIBUTES | DELETE did the trick instead of FILE_ANY_ACCESS.

Urg. Files with RO bit I guess…

Yeah, it appears that is the reason (they were all RO, but I cannot tell if any other were also RO, but did not fail, as there are >10K files in the cache).
I find this strange, I can request DELETE access in the same open for RO-bit clearing, but not WRITE_DATA access in it. The peculiar part being that I can get DELETE access, without needing a second open, after clearing the RO attribute.

I suppose its like ejecting the floppy, putting tape over the RO tab and putting it back in again, then deleting (and may be date to needing to simulate that)

RO files are a complete pain in mutliple ways but this is the most aggravating. Almost equally aggravating are directory ACLs where you can create an entry, but not read it (so you can create a new file, but you cannot then open it). And then there are files open for write but with the RO bit set…

Filesystems are weird.

Dejan, the traditional way to delete a readonly file is to toggle the readonly attribute off. That’s what “del /f” does from the command line. To do this efficiently from a filter open for DELETE access (but not DELETE_ON_CLOSE), set disposition, and if that fails with STATUS_CANNOT_DELETE you can check if the file is readonly (the only other reason for STATUS_CANNOT_DELETE being someone has a mapped view), and if so then toggle readonly off, set disposition again.
In RS3+, on NTFS, the DELETE_ON_CLOSE should work if you specify IO_IGNORE_READONLY_ATTRIBUTE (0x40) in addition to IO_IGNORE_SHARE_ACCESS_CHECK which you are already specifying. For some reason this doesn’t appear to be documented.
In RS5+, on NTFS, you can set FileDispositionInformationEx and pass the flag FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE. This one also appears to be undocumented at the moment. The documentation really is sorely out of date.

OK, another missing post sent via e-mail here…
Thanks for that info.
I doubt the new classes will be of any use, as it is extremely rare that only the latest OS needs to be supported.

We still have a great number of XP Clients, more than W10.

That’s unfortunate you will have so many XP clients. You could still send the new info class to take advantage of it on newer OSes, and fall back to old methods if it fails, but that’s your decision.

I’ve added some verbiage to the documentation about what STATUS_CANNOT_DELETE means, and also added FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE: