[9.0a x64] Can't del sub-folders in folder accessed as Admin

[Simson]

When changing into a folder that has no access rights for the current user I get the message "Access denied on the file [full path of folder name]". Then I can select "As Administrator" to get into this folder. Within this folder I can delete files with double confirmation but I cannot delete any sub-folders. Is this a bug, a feature or just an option for which I did not find the appropriate configuration.?

Update 1:
Further on I cannot open the Properties Window (by typing "Alt+Enter" or by right click) of a file or sub-folder when I accessed the parent folder as Admin. I seems that the ACL gained by pressing "As Administrator" are not further used/ remembered for any actions within the respective folder.

Thanks for any help, Simson.

[gdpr deleted 6]

Confirmed with TC64 9.0a

Looks to me like a problem with the user privilege elevation under certain circumstances.

Running TC as a normal (restricted) user, and trying to delete a folder with sub-folders requiring user privilege elevation ("as administrator") doesn't seem to work properly always.

On the other hand, running TC itself with administrator rights allows to delete the folder including its sub-folders without problems.

I suspect that particular file/folder access rights do play a role here. Need to investigate further...

[gdpr deleted 6]

Tested version: TC64 9.0a
OS: Windows 7 Pro x64 english

Update: As suspected in my previous post, ACLs play a role here.

And it looks like it is a bug.

How to reproduce:

1. Create the following folder structure using the Administrator account (which ensures that the owner of the folders will be the Administrator). Note that all of these are folders. No files are involved.

Code: Select all

x:\Test
    |
    +-- IWantDeleteThis
          |
          +-- SubFolderA
          +-- SubFolderB

2. Configure the ACL of the "IWantDeleteThis" in the following way:
- Remove any permissions inherited from its parent folder.
- Only has one permission entry for the Administrator with Full control.
It should look like this screenshot: http://imgur.com/a/DqchN

3. Verify that the two sub-folders "SubFolderA" and "SubFolderB" still inherit permissions from their parent. If that's the case, the test can commence.

4.1. Start TC as a normal, restricted user. Try to delete the folder "IWantDeleteThis".

4.2. UAC asks for administrator password.

4.3. TC with elevated permissions fails to delete the folder "IWantDeleteThis" and its sub-folders. The sub-folders also cannot be deleted individually.

5.1. Start TC as Administrator. Again, try to delete the folder "IWantDeleteThis".

5.2. When TC is executed as Administrator (and thus not needing privilege elevation), it can delete "IWantDeleteThis" and its sub-folders just fine.

6.1. To confirm that this is a bug in TC and not a system limitation, we try the same with the Windows Explorer.

6.2. Make sure you are logged in as a normal restricted user. Try to permanently delete the folder "IWantDeleteThis" in Windows Explorer (SHIFT+DELETE).

6.3. UAC asks for administrator password.

6.4. Windows Explorer with elevated permissions deletes the folder and its sub-folders just fine.


Quick summary of the above: TC does not seem to do the privilege elevation correctly. For files/folder with certain ACLs, even privilege elevation does not allow TC to delete them. However, this does not seem to be a system limitation but rather looks to me like a bug in TC (or limitation in Lazarus), because Windows Explorer can delete those files/folders using privilege elevation.

[gdpr deleted 6]

Final update:

TC64 8.52a also suffer from this privilege elevation issue, but not exactly in the same manner as the new Niner version(s)...

TC64 8.52a also fails deleting the folder and its sub-folders (from the example scenario i described in my last post) with privilege elevation, but only if the folder has not been inspected yet. Inspecting the folder "IWantDeleteThis", which also requests privilege elevation, somehow enables TC64 8.52a to delete the folder and its sub-folders.

In TC64 9.0a it does not matter whether i inspect the folder or not, it simply cannot delete it with privilege elevation. Weird bug...

[Simson]

Thanks elgonzo for digging deeper into the details of the issue I posted. I can confirm you further findings.

My summary so far is, that TC does not remember the privilege elevation gained by entering a folder for any further commands executed within that folder.

[gdpr deleted 6]

Thanks elgonzo for digging deeper into the details of the issue I posted. I can confirm you further findings.

My summary so far is, that TC does not remember the privilege elevation gained by entering a folder for any further commands executed within that folder.

No, that's likely not the case. Note that the issue is closely linked with non-standard ACLs.

Here is what i think goes wrong. Keep in mind that this is only my speculation and only addressed towards you. Christian knows much better than you and me how TC works in detail, and he does not really need my speculations about implementation details of TC

With that out of the way, here my speculations:

First, be aware that when TC needs to do something with elevated privileges, it starts TCMADMIN.EXE or TCMADM64.EXE (depending on whether you run TC32 or TC64). These executables are running with administrator privileges and doing the actual work / function calls requiring admin rights. (You can observe this in the Task Manager).

Based on the observed behavior when trying to delete a directory like "IWantDeleteThis" from my example above, i think that only the Total Commander process itself attempts to enumerate the directory content, and then only tells TCMADMIN.EXE/TCMADM64.EXE in some form about that directory content that has to be deleted.

And this would be the step where the issue as observed by you and me could manifest.

The ACL for the directory "IWantDeleteThis" does not include any permissions except for the Administrator account. With such an ACL, Total Commander running under the normal, restricted user account would not even be permitted to enumerate the content of the directory.

Note that the simple operation of entering/inspecting such a directory like "IWantDeleteThis" from my example does not pose a problem for TC. It works. Even though the Total Commander process itself cannot enumerate the directory content. Which pretty much is evidence that for this operation the enumeration of the directory is properly offloaded to TCMADMIN.EXE/TCMADM64.EXE (which of course can enumerate the content of "IWantDeleteThis", because ACL and admin privileges...).

Then, why does the deletion of this directory does not work? I guess, when initiating the deletion of the folder, Total Commander simply wants to do the directory enumeration itself -- which of course fails, because Total Commander is being denied by the directory's ACL. And my speculation is that Total Commander not offloading the directory enumeration to TCMADMIN.EXE/TCMADM64.EXE for such a delete operation is the root cause for the bug. No successful directory enumeration - no deletion happening. It could be as simple as that.

If my speculation is indeed true (remember, it's still only my speculation so far), then a fix should hopefully be relatively easy: the deletion operation would only be required to do the very same thing TC already does for entering/inspecting a directory: offloading the directory content enumeration to TCMADMIN.EXE/TCMADM64.EXE...

(Oh, and don't ask me how the weird behavior of TC 8.52a i observed would fit into this picture. I have no idea... There would be more/other things required -like caching the last visited directory or so- to explain TC 8.52a's weird behavior...)

[ghisler(Author)]

Thanks, I will check it. It should definitely work when the user entered the subfolders manually, like this:

Inspecting the folder "IWantDeleteThis", which also requests privilege elevation, somehow enables TC64 8.52a to delete the folder and its sub-folders.

I will check why this is no longer working in TC9.

[gdpr deleted 6]

Thanks, I will check it. It should definitely work when the user entered the subfolders manually, like this:

Inspecting the folder "IWantDeleteThis", which also requests privilege elevation, somehow enables TC64 8.52a to delete the folder and its sub-folders.

I will check why this is no longer working in TC9.

Shouldn't it also work without entering the folder manually first?

There is no reason in demanding the user to enter the directory manually before it can be deleted just because the normal user account does not have permissions to enumerate the directory content. Approving the UAC request for the deletion of the directory is all the user should need to do, regardless of whether the user has visited that directory before or not.

[ghisler(Author)]

Shouldn't it also work without entering the folder manually first?

No, this would be quite risky to lose important system files.

[gdpr deleted 6]

Shouldn't it also work without entering the folder manually first?

No, this would be quite risky to lose important system files.

You are right. Didn't think of that.

Although, there is still a part of me that wonders why TC running as administrator is not having the same safety measure. After all, what would make a user deciding to run TC as administrator (right-click on TC icon and select "Run as administrator") more competent than a user who grants administrator privileges for certain actions (through UAC) on a case-by-case basis...? Is this perhaps unintentional behavior of TC when run as administrator?

Anyway, It would be a good idea, though, to inform the user about this safety measure instead of presenting a nondescript "This directory cannot be deleted. Skip/Retry" dialog...

[MVV]

I think that TC shouldn't forbid deletion a folder w/o entering it first, it is not a file manager problem, file manager should do what user needs. It should allow deletion of any folder (maybe with additional confirmation if admin rights are required). Most operations that TC already allows to do are may be dangerous, and it is user who should take care of consequences.

[DrShark]

It seems that if the folder with restricted access rights has a read-only attribute, TC doesn't delete it even after entering.
On 32-bit Vista it can be reproduced with Program files\ folder.
Launch not-elavated TC, go to %programfiles% and make a subfolder Test\ there.
Then using elevated cmd.exe and the command attrib +r test apply the read-only attribute to this folder.
Now go back to not-elavated TC.
You can enter the Test\ folder with TC and even copy some files to it from opposite panel.
Then return to Program files\ folder and try to remove this test folder: it will fail even after the confirmation of the elevation request, TC then will show the dialog with Skip, Skip all, Retry and Abort options where Retry will show that dialog again.

[gdpr deleted 6]

It seems that if the folder with restricted access rights has a read-only attribute, TC doesn't delete it even after entering.
On 32-bit Vista it can be reproduced with Program files\ folder.
Launch not-elavated TC, go to %programfiles% and make a subfolder Test\ there.
Then using elevated cmd.exe and the command attrib +r test apply the read-only attribute to this folder.
Now go back to not-elavated TC.
You can enter the Test\ folder with TC and even copy some files to it from opposite panel.
Then return to Program files\ folder and try to remove this test folder: it will fail even after the confirmation of the elevation request, TC then will show the dialog with Skip, Skip all, Retry and Abort options where Retry will show that dialog again.

I can confirm. Nice find!

[ghisler(Author)]

Sorry, I prefer to keep it this way.

[DrShark]

Sorry, I prefer to keep it this way.

I really don't understand this limitation. It means that if I move a lot of files (100 000 and more) from e.g. backup hdd to a new system and I want to be sure that I'll really move (no matter whether it's one step move or two step copy+delete) all folders and files I'll have either to start TC with highest possible rights or I'll have to change the permissions for whole file-folder tree before I'll start to move or delete files in not-elevated TC. This "change permissions" process iself may can take hours for thousands of folders and files and AFAIR a long time ago when I tried this on Windows XP for a folder with more than 300 000 subfolders/files it even crashed my PC with BSOD.