Access Denied

[admin]

Thanks for the additional info. The next version will feature an attempt to fix it. While XY (i.e. the API it uses) normally resolves junctions as expected, for unknown reasons these particular junctions are not resolved by the API. My fix is to resolve them manually and then feed the junction target to the API. Let's see if this works.

If yes, then I will have to apply the fix also to some other points in my code (just a reminder to myself...).

[nas8e9]

Thanks for the additional info. The next version will feature an attempt to fix it. While XY (i.e. the API it uses) normally resolves junctions as expected, for unknown reasons these particular junctions are not resolved by the API. My fix is to resolve them manually and then feed the junction target to the API. Let's see if this works.

If yes, then I will have to apply the fix also to some other points in my code (just a reminder to myself...).

The difference in the ability to resolve this junction is allegedly because of the ACL it has on it. Just curious: since the root of this problem is getting the (My) Documents, Pictures and Videos shell folders, does MSDN prescribe access (for Vista and later) through the Documents and Settings junction or through the registry and/or a Windows API?

[ogroeger]

I can't confirm this:

WE can't, like XYplorer, browse C:\Documents and Settings itself. Please see the attached screenshots.

My observation is:

• Clicking on C:\Documents and Settings results in Access denied with WE and XY
• Autocompletion of C:\Documents and Settings in the address bar returns no result in WE and XY
• Autocompletion of C:\Documents and Settings\Olaf in the address bar returns results in WE and XY
• Confirming of C:\Documents and Settings\Olaf in the address bar returns results in WE and Not Found in XY
• Confirming of C:\Documents and Settings\Olaf\Desktop in the address bar returns results in WE and Access Denied in XY

Another point is visualization and localization:

• Listing C:\ in WE showns one (normal) Programme folder and one Programme folder with a lock icon (Acces denied when you click on it)
• Listing C:\ in XY showns one (normal) Program Files folder and one Programme folder with a lock icon (Acces denied when you click on it)
• WE shows a (normal) Benutzer folder, XY a (normal) Users folder
• WE shows the folder C:\Benutzer\Olaf as icon with lock folder while you can browse it. XY behave identical (with folder C:\Users\Olaf
• WE and XY show the folder C:\Benutzer\Olaf\Eigene Dateien, resp C:\Users\Olaf\Eigene Dateien as folder without lock, though they give Access denied while clicking on it

Conclusion:

• Using mouse clicks WE and XY behave identical
• The address bar differs
• The use of the lock icon is not understandable for me (seems not to correlate with "This folder is locked for you")

[nas8e9]

I can't confirm this:

WE can't, like XYplorer, browse C:\Documents and Settings itself. Please see the attached screenshots.

My observation is:

• Clicking on C:\Documents and Settings results in Access denied with WE and XY
• Autocompletion of C:\Documents and Settings in the address bar returns no result in WE and XY
• Autocompletion of C:\Documents and Settings\Olaf in the address bar returns results in WE and XY
• Confirming of C:\Documents and Settings\Olaf in the address bar returns results in WE and Not Found in XY
• Confirming of C:\Documents and Settings\Olaf\Desktop in the address bar returns results in WE and Access Denied in XY

Another point is visualization and localization:

• Listing C:\ in WE showns one (normal) Programme folder and one Programme folder with a lock icon (Acces denied when you click on it)
• Listing C:\ in XY showns one (normal) Program Files folder and one Programme folder with a lock icon (Acces denied when you click on it)
• WE shows a (normal) Benutzer folder, XY a (normal) Users folder
• WE shows the folder C:\Benutzer\Olaf as icon with lock folder while you can browse it. XY behave identical (with folder C:\Users\Olaf
• WE and XY show the folder C:\Benutzer\Olaf\Eigene Dateien, resp C:\Users\Olaf\Eigene Dateien as folder without lock, though they give Access denied while clicking on it

Conclusion:

• Using mouse clicks WE and XY behave identical
• The address bar differs
• The use of the lock icon is not understandable for me (seems not to correlate with "This folder is locked for you")

To state the obvious: you're using a localized version of either Windows Vista or Windows 7. That explains the (physical) \Program Files and \Users (with English, not translated names) folders as well as, probably, the junctions with the localized names (\Programma and \Benutzer). To put it another way, I suspect all language versions of Windows have the physical folders \Program Files and Users, while localized versions have additionally junctions with localized, translated names pointing to the physical folders with the original, English names, to enable users to access these folders through native-language names.

These junctions also seem (though I'm not English, I do use an English, non-localized version myself so I can't test this) to have a restrictive ACL, meaning you can only navigate through them but you can't browse the junctions themselves.

It's worth noting that WE by default does not show hidden folders and files. By leaving this setting off you should only see translated names for \Program Files and \Users which should just work. Is this the case for you? Also, could you post the output of

dir /a /o:gne

in the root of C: (C:\) which should list the junctions?

[ogroeger]

To state the obvious: you're using a localized version of either Windows Vista or Windows 7. That explains the (physical) \Program Files and \Users (with English, not translated names) folders as well as, probably, the junctions with the localized names (\Programma and \Benutzer). To put it another way, I suspect all language versions of Windows have the physical folders \Program Files and Users, while localized versions have additionally junctions with localized, translated names pointing to the physical folders with the original, English names, to enable users to access these folders through native-language names.

These junctions also seem (though I'm not English, I do use an English, non-localized version myself so I can't test this) to have a restrictive ACL, meaning you can only navigate through them but you can't browse the junctions themselves.

It's worth noting that WE by default does not show hidden folders and files. By leaving this setting off you should only see translated names for \Program Files and \Users which should just work.

Thank you for your (technical) explanations. But i think you missed the point i wanted to adress. WE as well as XY are end user products and should have a clear and easy to understand GUI. Please see this Screenshot from WE:



It make no sense because it shows the same thing twice, but with different properties (at least the icons induce this).

And now see this screenshot from XY:



It makes no sense because it shows the same thing with different names.

Maybe i caused this misunderstanding because i added my point to the more technical discussion about user rights, but my goal was that a solution of the access problems could be done together with a reasonable GUI change.

[nas8e9]

Thank you for your (technical) explanations. But i think you missed the point i wanted to adress. WE as well as XY are end user products and should have a clear and easy to understand GUI. Please see this Screenshot from WE:



It make no sense because it shows the same thing twice, but with different properties (at least the icons induce this).

And now see this screenshot from XY:



It makes no sense because it shows the same thing with different names.

The duplicate folders have two versions: one normal and accessible, the other lightly shaded (indicating a hidden folder/junction) and with a locked icon. The reason I mentioned WE *not* showing hidden files and folders by default, is that by using that setting you get a coherent, easily usable view. Going by the screen shots, you have both WE as well as XYplorer set to display hidden files and folders, causing you to see the "plumbing" necessary for legacy compatibility (\Documents and Settings) and localization of the shell space (\Programme and \Benutzer).

Maybe i caused this misunderstanding because i added my point to the more technical discussion about user rights, but my goal was that a solution of the access problems could be done together with a reasonable GUI change.

If you'd want to spare yourself that confusion, you'd have to disable the display of hidden files and folders. If that is not a workable solution for you, things get messy very quickly with code needing to be added for different Windows versions (XP vs. Vista/7) as well as for localized/non-localized versions.

The fundamental difference between WE and XYplorer is that WE shows a shell space with not just the physical files and folders but with additional functionality represented by folders and items. Furthermore, it's meant to be as easy as possible and to achieve that, it may reduce and simplify things (not showing file extensions by default is a rather infamous example). XYplorer on the other hand, is first and foremost a file manager. If Windows adds plumbing in the form of physical folders, junctions and/or files, it will display these. It's more or less a power user tool, after all!

[fredzoyt]

So, bottom line: will XY eventually be able to access these restricted folders? I'm currently evaluating and I'm discovering that XY is lacking in a couple things that I'm bummed about because I'm so wanting to buy to replace WE.

Dave

[admin]

So, bottom line: will XY eventually be able to access these restricted folders? I'm currently evaluating and I'm discovering that XY is lacking in a couple things that I'm bummed about because I'm so wanting to buy to replace WE.

Dave

This is fixed in 9.10. Isn't it?

[fredzoyt]

So, bottom line: will XY eventually be able to access these restricted folders? I'm currently evaluating and I'm discovering that XY is lacking in a couple things that I'm bummed about because I'm so wanting to buy to replace WE.

Dave

This is fixed in 9.10. Isn't it?

Oh it is? I'm unable still to access them. I'm probably doing something wrong. I do have the UAC(?) turned off.

Dave

p.s. Thanks for the lightening fast reply. The one thing this program has going for it (from what I've seen in the forums) is great customer support. I was a long time user of File Note Organizer, which now is a dead in the water project; so I'm eager to find a good replacement.

[admin]

So, bottom line: will XY eventually be able to access these restricted folders? I'm currently evaluating and I'm discovering that XY is lacking in a couple things that I'm bummed about because I'm so wanting to buy to replace WE.

Dave

This is fixed in 9.10. Isn't it?

Oh it is? I'm unable still to access them. I'm probably doing something wrong. I do have the UAC(?) turned off.

Dave

p.s. Thanks for the lightening fast reply. The one thing this program has going for it (from what I've seen in the forums) is great customer support. I was a long time user of File Note Organizer, which now is a dead in the water project; so I'm eager to find a good replacement.

What folder for example gets you access denied? And when you right-clilck that folder, do you get information about a junction?

[fredzoyt]

So, bottom line: will XY eventually be able to access these restricted folders? I'm currently evaluating and I'm discovering that XY is lacking in a couple things that I'm bummed about because I'm so wanting to buy to replace WE.

Dave

This is fixed in 9.10. Isn't it?

Oh it is? I'm unable still to access them. I'm probably doing something wrong. I do have the UAC(?) turned off.

Dave

p.s. Thanks for the lightening fast reply. The one thing this program has going for it (from what I've seen in the forums) is great customer support. I was a long time user of File Note Organizer, which now is a dead in the water project; so I'm eager to find a good replacement.

What folder for example gets you access denied? And when you right-clilck that folder, do you get information about a junction?

Well, under "users default" I do see the "junction" tab, but when I check that it takes me where (I assume) the root is. But it does take a lot of clicks to take me where I eventually want to go. I suppose it's just a hassle more than anything else. I can learn to live with it I reckon. I'm getting ready to finish testing xplorer2, which I don't has this built in limitation.

thanks again for the help,
Dave

[admin]

Well, under "users default" I do see the "junction" tab, but when I check that it takes me where (I assume) the root is. But it does take a lot of clicks to take me where I eventually want to go. I suppose it's just a hassle more than anything else.

I did not suggest to go that way. I'm just trying to find out why it does not work. If you are using 9.10 and the folder in question is a junction, then there is only one possible reason left: XY cannot access the junction target for some reason. Is there anything special about the junction target in your case?