Why am I unable to delete files?

[mathewsdw]

Like so many things I seem to get involved in, I think this is best illustrated by following an actual, real-world, TCC session step-by-step. So first, as a starting point:

[Z:\]Ver
TCC  12.11.76   Windows 7 [Version 6.1.7601]

Obviously Windows 7. (Incidentally, it's Windows 7 Professional.)

[Z:\]Echo %_Admin %_WinUser
1 Administrator

As you can see, not only am I an "elevated" user, I'm actually logged in under the true "Administrator" account in Windows 7. (I don't think it's even possible to be more "elevated" than this! :) )

[Z:\]CDD D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode

Here I went to the directory whose name suggests what the problem is:

[D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode]Dir /K /M /H
 9/27/2010  15:07          78,848  Sample1.txt
11/04/2011  14:26          37,376  Sample2.txt
 9/27/2010  16:57         105,984  Sample3.txt
12/27/2010  15:10          49,664  Sample4.txt
 2/19/2012   9:06          36,352  Sample5.txt
 9/27/2010  15:24         103,424  Sample6.txt

This shows what is in that directory, just ordinary-looking files.

[D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode]Attrib *
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample1.txt
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample2.txt
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample3.txt
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample4.txt
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample5.txt
___A__________  D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample6.txt

And you can see above that they have only the completely-normal "Archive" attribute set.

So below is the problem in all of its glory:

[D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode]Del Sample?.txt
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample1.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample1.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample2.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample2.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample3.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample3.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample4.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample4.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample5.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample5.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample6.txt
TCC: (Sys) Access is denied.
 "D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample6.txt"
     0 files deleted       6 failed

If even a true administrator can't delete these files, who can? And how did files like this even get created, anyway???

This is a completely real-world situation, not some kind of "made up" example. How can files even exist that can not be deleted by an "Administrator" who is as "administrative" as it is even possible to be?

- Dan

 

[mfarah]

A possible reason is that each of those files may have a handle pointing to it, and that's what won't allow the file to be deleted. The Sysinternals "handle" tool (a command-line utility) will shed light on this.

Other possibility: what are the directory's ("TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode") attributes?

Also: can you create/delete other files in that directory?

 

[Joe Caverly]

So below is the problem in all of its glory:

[D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode]Del Sample?.txt
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample1.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample1.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample2.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample2.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample3.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample3.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample4.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample4.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample5.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample5.txt"
Deleting D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample6.txt
TCC: (Sys) Access is denied.
"D:\TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode\Sample6.txt"
    0 files deleted      6 failed

As a test, can you delete the files using Windows Explorer?

Joe

 

[Charles Dye]

It's obviously not the attributes, so I'd check the permissions next. Yes, it is possible to set the permissions to deny access to the administrator! But, as administrator, you can always "take ownership" and reset the permissions.

And while it's certainly possible to do these things through the command line, this is one of those tasks which is actually easier in the GUI. (To take ownership in a batch file, I've used a third-party program called CHOWN, by one Alexander Frink. You can change permissions with CACLS, included with Windows.)

 

[mathewsdw]

Thank you for your answers, guys. But Rex e-mailed me a suggestion (because it came up in terms of another problem that I had e-mailed "support" about because the issue that started the whole thing was my need to re-install Take Command/TCC due to a stupid error (I'm rather fond of those!!! :) ) I had made and then I couldn't find the key and then some "issues" I had after doing that. Rex sending me my key was "private", of course, and the rest so strange and weird and absolutely related to my re-installation that the rest of the issues that arose, other than this one, I took up privately with Rex. So Rex suggested that there was one (or more) TCC sessions that still had a "handle" on the files in that directory, and I started Task Manager up and that was indeed the case, so when I cancelled those TCC sessions I was able to delete the files as I wanted.

I will add here that I would have expected the "TCC: (Sys) The process cannot access the file because it is being used by another process." error and not an "Access denied" error. I find that very strange. And given that I got an "Access denied" error rather than "being used" error, it didn't even occur to me to find out what had a "handle" on the file(s). (I will note here that the SysInternals "handle" command is almost useless in Windows 7 because it will not run at all from a non-administrative command prompt and (this is the worst part) doesn't necessarily "see" "handles" created by non-administrative processes when running in administrative mode, making it effectively useless in Windows 7. Rather strangely, this is not true for the GUI "Process Explorer" program from SysInternals, but since that program is a pure GUI program I tend to avoid using it whenever possible because of my vision issues.)

But I will make the observation that there were several strange things going on here. Number one, the TCC sessions in question (there were actually two of them) were evidently in "invisible" windows because they only showed up in "Processes" tab of the Task Manager and not at all in the "Applications" tab of same. The question is "how could that have happened?" since I am not in the habit of creating "invisible" TCC sessions. Number 2, I was able to rename all of those files and the directory containing them (the original names of the files were not "Sample#.txt", and the name of the directory was not "TextFilesThatCanNotBeDeletedEvenInFullAdministrativeMode"), I had renamed them to separate where the files and directories came from and what they were for from the issue that I could not delete them. (And I will note that I was not only able to rename both the files and the directory containing them, I was also able to move that directory to the "root" of my D: drive from a several-levels-down subdirectory. Somehow, I would have thought that none of those things were doable when some program had a "handle" on a file.)

And Charles, I won't dispute that many things are doable in the GUI (and possibly sometimes more easily than from the command line) but I really can't effectively use the GUI due to my vision issues. That was probably the primary reason why I eventually became an almost-total command-line Geek, and, thankfully, TCC is far more powerful than any GUI could possibly be so I really don't miss the GUI in the slightest. (Frankly, I'd be in real trouble if TCC didn't exist. For the short period of time that I did not have a working copy of TCC and had to use the native command line program (cmd.exe) I found it so primitive as to be almost unusable.) And increasing the font sizes and the sizes of the various GUI elements really doesn't help because there isn't enough screen "real-estate" available to really make them large enough that I can easily see "enough" of them - I have to rely on the "Magnify" app which only shows a quite-limited portion of the screen at one time and I actually tend to avoid needing to use the "Magnify" app whenever possible; a relatively large font in TCC fits my needs perfectly.

And no, Joe, I could not delete them in Windows Explorer, either, although I did get "file is in use" error message rather than the "access denied" message which is different than what TCC reported and was as it should have been.

And Charles, I've never, ever set the "permissions" on anything (I don't even know how); I am the only user who ever uses this computer and it only has three accounts: the "real" Administrative account (which I have "resurrected"), the pseudo-administrative account which is what is created when you create the first account on the machine after installing Windows 7, and a non-administrative account which I originally created as a sort of "safety net" that I would use most of the time to keep me from "damaging" things by making stupid mistakes. However I found this pseudo-administrative account safe to use because of UAC, which I would absolutely never turn off under any circumstances. I keep an "elevated" TCC session open at all times in case I need it, but I (at least) attempt to only actually use it when really I do need it. Again, I find the chances of me making a stupid mistake that I will very much regret later to be far too high to do otherwise. (BTW, can programs be run in an "elevated" mode at all when run in a completely non-administrative account? If not, that would make a non-administrative basically useless for me in the normal course of events because I do things that actually do require administrative privileges probably dozens of times in any single day; and UAC offers "enough" protection for me in the general case.

- Dan

P. S. I will note that I have the "private" directories and files for all three accounts to be either symbolically or hard-linked together so that my "environment" in all three accounts is identical other than the "administrative" privileges that they each have.

 

[rconn]

I will add here that I would have expected the "TCC: (Sys) The process cannot access the file because it is being used by another process." error and not an "Access denied" error. I find that very strange. And given that I got an "Access denied" error rather than "being used" error, it didn't even occur to me to find out what had a "handle" on the file(s).

The error and the message text is coming from Windows, not TCC. There's not much I can do in TCC to extrapolate on what Windows might *really* mean.

But I will make the observation that there were several strange things going on here. Number one, the TCC sessions in question (there were actually two of them) were evidently in "invisible" windows because they only showed up in "Processes" tab of the Task Manager and not at all in the "Applications" tab of same.

That's normal for any TCC sessions running in Take Command tab windows. The consoles are started hidden, and their contents are displayed by Take Command in the tab windows. If you have a Take Command session crash for some reason, you'll end up with "orphaned" hidden TCC sessions. (Which you can then reattach to a new Take Command session.)

 

[mathewsdw]

Rex, re. your first answer, that is what I fully expected even though I got the "right" message in explorer which I think even you would find kind of strange (I'm not at doubting you). So it really comes down to "Why does Windows report the right error message in one case an not in another?", although there is probably nothing you can do about it; you are "told" what you are "told".

Re. your second answer, I had zero Take Command sessions open and I don't remember any crashing (not really reliable, of course) so they were somehow "orphaned" (and I have no clue as to how an why). However, there are times (not too many, thankfully!) when this machine does strange and unexpected things; maybe this is just another one...

I won't ask how to re-attach invisible TCC windows (or even how I would know that there are any in the general case.) :)

- Dan

 

[rconn]

Rex, re. your first answer, that is what I fully expected even though I got the "right" message in explorer which I think even you would find kind of strange (I'm not at doubting you).

Not really strange -- Explorer is using a different (much slower) API (one of the Windows shell COM interfaces) to delete files, so it's not surprising it would have different error returns.

 

[mathewsdw]

Rex, it's only not "strange" in the sense that one should not expect Microsoft to implement something both consistently and always correctly (in my opinion, the error message I was getting from TCC was, simply put, incorrect because it gave no indication whatsoever as to what the problem really was - but, as you say, not your fault).

But I wanted to add something more here - so a long introduction (that you may feel free to skip if you don't want to take the time to read it):

And that is that I have figured out exactly why I am taking the time to consistently brag to my friends and acquaintances about your product (and often boring them; frankly, I've only managed to get one person to actually buy it so far and he hasn't used it much the last time I checked because he says that he is overloaded and has already "figured out" how to do the things that he most often needs to do using other techniques and, being overloaded, he hasn't found the time to actually sit down and "learn" TCC) ; and I am not at exaggerating at all when I say that I literally could not survive on my own without your product and its power and capabilities and ease-of-use (the way one does almost anything is completely "logical", as Spock would have said, and almost obvious in hindsight) and truly for the most part excellent documentation (as I've noted multiple times in the past I am really dependent on good docs because just because I've done something a dozen or more times in the not-too-distant past doesn't mean that I'll remember how to do it the next time I need to do it - as I've also noted quite a few times in the past my memory problems are not at all humorous at this point in life).

So finally to the "heart" of what I've figured out - TCC, in particular, gives me such great joy (yes, that absolutely is the right word) that I want to share it with my friends and acquaintances. As I've said some number of times previously, thank you very much!!!

- Dan