can't access protected folders

[highend]

You don't really need to reset permissions back. It's a non-reversible thing (at least if done via File Explorer). With exceptions (icacls ... /reset)

Otherwise, in a 100% reliable way?

Before you call ShellExecute:
Backup permissions via

Code: Select all

icacls "<path>" /save "<file>" /t /c

When you want to restore them:

Code: Select all

icacls "<parent of path>" /restore "<file>"

Be careful, when <parent of path> is the root of a drive, you cannot quote it!

[admin]

Well, it's too late I guess.

[highend]

Nope

Save this as "C:\perms.txt"

Code: Select all

PerfLogs
D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OI;0x1200af;;;LU)S:AI

Open a command prompt with admin permissions in C:\
Execute:

Code: Select all

icacls C:\ /restore "C:\perms.txt"

[Filehero]

Code: Select all

v17.50.0203 - 2017-02-03 15:48
    + Browsing Protected Folders: Experimentally ......
      NOTE: Pressing "Continue" *permanently* changes your permissions regarding
      this folder. There is no easy way back to the original state.

Permanently as per XY session or as a persistent change to the file system / ACL?

[highend]

Mh...

Something is fishy here. When you invoke the dialog by trying to enter C:\PerfLogs
within XYplorer and accept it, it works.

BUT!

When you reset the permissions to their former state (through icacls) the File Explorer
asks for permission next time you try to enter the folder (cancelling the dialog after)
but XY will never ask you again?

Even a fresh instance or a XY restart doesn't change that here. You'll immediately see
the "Permission denied" C:\PerfLogs kind of background image when you enter the
folder...

[Dustydog]

[Highend - really appreciate your excellent summary, etc. (And your activity here generally.)]

One thing I thought I'd add - that may not be of any interest to the original poster, but may be useful for someone else who lands here from a search:

Sometimes, if you're trying to access a system folder, you may become baffled at the lack of access. This may be because the folder is not actually a folder, but a symbolic link to the actual folder, which is where you need to get in order to set access and open things up. (Metro/Universal app folders are a mess - don't even bother unless you know something I don't and can ignore this.)

These are in place primarily for backwards compatibility (one nice thing about Windows). Otherwise, it's a bit like changing the permissions on a shortcut - it won't matter to the target file, just the shortcut.

Also, there's a few folders (like the user folders) that have some programming associated with them, so they go beyond simple links (have a care with them). Junctions, though incredibly useful, you won't likely find within Windows per se because they're primarily used for creating a folder link to a different partition or drive. You can think of these links as being able to fool the operating system into thinking something is at location A, when actually the data is at location B - as well and in the usual way.

***Some General Comments***

Links can be useful when you want something in more than one place, but don't want to use any extra space - or simply want to offload data to another location invisibly to Windows - which can be handy for those with small SSDs as their primary drive, for example.

A Junction or Hardlinks can also be useful if you want to create a folder of things you want to back up regularly and conveniently. Back up a junction to a network location, for example, and you won't get something like a shortcut, you'll get the data inside.

Hope this gives someone interested a place to start Googling. Hardlink Shell Extender http://schinagl.priv.at/nt/hardlinkshel ... nsion.html is a useful Windows Shell extension that has excellent documentation and is a good place to start learning. It also can create some useful, complicated, automatic structures as well as the expected hardlinks, symbolic links, and junctions, and if you read the documentation and get around Window's stupid limit on overlays - some handy overlays if you wish them (OneDrive uses up too many of the overlays, so you have to prioritize in the registry - the site documents how to do this - this tiny limit on overlays is one dumb thing about Windows).

Hardlinks are different. They're essentially a dual reference to a file and act in all ways just like a normal file - only to delete you have to delete the last hardlink. But hardlinks are for files only, not folders, and they have to be within the same partition.

XY, ofc, supports easy creation of advanced link types natively under Paste Special.

That said, the documentation, overlays, and some of the automatic structures are still worth it, imho, for the above utility. (Ignore any antivirus warnings if you get one - it's been around for ages, is reliable, but it does tricky things and periodically gets false algorithmic positives.)

[admin]

Nope

Save this as "C:\perms.txt"

Code: Select all

PerfLogs
D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OI;0x1200af;;;LU)S:AI

Open a command prompt with admin permissions in C:\
Execute:

Code: Select all

icacls C:\ /restore "C:\perms.txt"

Thanks. But it did not work ("C:\perms.txt" definitely exists):

[admin]

Code: Select all

v17.50.0203 - 2017-02-03 15:48
    + Browsing Protected Folders: Experimentally ......
      NOTE: Pressing "Continue" *permanently* changes your permissions regarding
      this folder. There is no easy way back to the original state.

Permanently as per XY session or as a persistent change to the file system / ACL?

Forever!

[highend]

Save it with UTF-16 LE (no BOM!)

[admin]

(gotta go now, later...)

[admin]

Something is fishy here. When you invoke the dialog by trying to enter C:\PerfLogs
within XYplorer and accept it, it works.

BUT!

When you reset the permissions to their former state (through icacls) the File Explorer
asks for permission next time you try to enter the folder (cancelling the dialog after)
but XY will never ask you again?

Even a fresh instance or a XY restart doesn't change that here. You'll immediately see
the "Permission denied" C:\PerfLogs kind of background image when you enter the
folder...

Yep, confirmed and fixed. It seems there is no way around temporarily opening Explorer together with the prompt -- else you are punished with fishiness. Not a big issue. All this is a very rare situation anyways.

[Marco]

I think that WE works by injecting some user token into itself, via UAC, to temporarily gain access privileges to protected folders. That would explain the fishiness in accessing such folders by actually changing their permissions instead.

[admin]

I think that WE works by injecting some user token into itself, via UAC, to temporarily gain access privileges to protected folders. That would explain the fishiness in accessing such folders by actually changing their permissions instead.

I'm not sure. When I gain access to PerfLogs via WE it's also permanent. No apparent difference to XY.

[highend]

While I can't explain XY's behavior in this case, the File Explorer physically modifies the dacl of that folder, adding the current user to it.
The difference is clearly visible when you use

Code: Select all

icacls "C:\PerfLogs"

before and after acknowledging the permission dialog

[ckp]

in my opinion, a fix should just mirror what happens in file explorer, which is a permanent permissions change and no more prompting to get in there. of course, if that particular folder gets removed and put back with the limited permissions again, you should be back to getting that prompt one time again.