Another Win7 (and possibly Vista) related Request

[Creat]

How does the redirecting work? Junctions?

Do you mean the redirecting of the file-writes to folders like 'program files'? Or the way Win Explorer can redirect you to the corresponding 'virtual folder' for one where redirects have happened?
In case that is what you mean, for a program not aware of the possibility of redirections (and not running with full admin rights), it sees the contents of both folders merged. So if "program files\testfolder" contains a.txt and the corresponding compatiblity folder (usualy "[systemdrive]\users\[username]\Appdata\Local\VirtualStore\Program Files\testfolder") contains b.txt, a program would see both of them if it lists the contents of "program files\testfolder". A program running with administrative rights would only see a.txt.
This allows for weird situations, where two files seem to be in the same folder with the exact same filename!
Did this answer your question?

[admin]

How does the redirecting work? Junctions?

Do you mean the redirecting of the file-writes to folders like 'program files'? Or the way Win Explorer can redirect you to the corresponding 'virtual folder' for one where redirects have happened?
In case that is what you mean, for a program not aware of the possibility of redirections (and not running with full admin rights), it sees the contents of both folders merged. So if "program files\testfolder" contains a.txt and the corresponding compatiblity folder (usualy "[systemdrive]\users\[username]\Appdata\Local\VirtualStore\Program Files\testfolder") contains b.txt, a program would see both of them if it lists the contents of "program files\testfolder". A program running with administrative rights would only see a.txt.
This allows for weird situations, where two files seem to be in the same folder with the exact same filename!
Did this answer your question?

Thanks, but I meant your first interpretation: the redirecting of the file-writes to folders like 'program files'?

[Creat]

Thanks, but I meant your first interpretation: the redirecting of the file-writes to folders like 'program files'?

Ah OK then
Well there actually isn't much to tell really. If you execute any operation from an application in a non-elevated state, that should result in creating a non-.exe file in program files or a subdirectory, the file is instead created in the corresponding VirtualStore folder. I haven't tested thoroughly how this affects writing to already existing files, but as far as I can tell from experience so far it gets copied to the VirtualStore and then the modifying write operation happens. I'm not entirely sure hot it's decided which of these two files then gets opened on a subsequent open operation.
As previously noted .exe-files are still copied to program files (after a UAC request to the user), and this therefore automatically fails if attempted from a limited (non-admin) user-context. But even if a single copy-operation contains an .exe and a lot of other files, only the exe file is placed in program files after that UAC request and the others still end up in the VirtualStore.
I'm not entirely sure on every mechanic, I didn't read much about it and all of this comes from just observing what happens, but I'll also try to find some more information on this

[admin]

Thanks, but I meant your first interpretation: the redirecting of the file-writes to folders like 'program files'?

Ah OK then
Well there actually isn't much to tell really. If you execute any operation from an application in a non-elevated state, that should result in creating a non-.exe file in program files or a subdirectory, the file is instead created in the corresponding VirtualStore folder. I haven't tested thoroughly how this affects writing to already existing files, but as far as I can tell from experience so far it gets copied to the VirtualStore and then the modifying write operation happens. I'm not entirely sure hot it's decided which of these two files then gets opened on a subsequent open operation.
As previously noted .exe-files are still copied to program files (after a UAC request to the user), and this therefore automatically fails if attempted from a limited (non-admin) user-context. But even if a single copy-operation contains an .exe and a lot of other files, only the exe file is placed in program files after that UAC request and the others still end up in the VirtualStore.
I'm not entirely sure on every mechanic, I didn't read much about it and all of this comes from just observing what happens, but I'll also try to find some more information on this

Thanks. I think the natural immediate reaction to this scenario is: HRXghLLpsx (sound of cutting throat). But OTOH, it's still harmless compared to a German tax declaration.

[Creat]

To be honest I think this actually makes sense (as long as there is a way to know weather a file is actually located there or in the VirtualStore), even though this may not be the popular point of view. Think of all the problems this solves (viruses infecting executable files in 'program files' and/or the windows folder, to name just one).
The VirtualStore solution is just a necessary way to allow programs to seemingly write there, since a lot of them (like XYplorer, at least by default) keep their settings there. The intended way (at least by Microsoft) to handle per user versus all user settings would be to keep them either in [user directory]\appdata versus [allusers]\appdata (could obviously be changeable . Personally I think it makes sense to separate program files and settings, and this encourages developers to do so. It even creates per-user settings for programs that didn't bother with that option (though programmers have to explicitly care if they want shared settings now).
This is all obviously only valid if there is a way for programs like file managers and the like to get around this and know when they have to do so, or better even know when a file isn't actually located where it seems to be. Maybe there is (or can be, if the right function is called) now a new flag set when listing files carrying just this information.

[admin]

To be honest I think this actually makes sense (as long as there is a way to know weather a file is actually located there or in the VirtualStore), even though this may not be the popular point of view. Think of all the problems this solves (viruses infecting executable files in 'program files' and/or the windows folder, to name just one).
The VirtualStore solution is just a necessary way to allow programs to seemingly write there, since a lot of them (like XYplorer, at least by default) keep their settings there. The intended way (at least by Microsoft) to handle per user versus all user settings would be to keep them either in [user directory]\appdata versus [allusers]\appdata (could obviously be changeable . Personally I think it makes sense to separate program files and settings, and this encourages developers to do so. It even creates per-user settings for programs that didn't bother with that option (though programmers have to explicitly care if they want shared settings now).
This is all obviously only valid if there is a way for programs like file managers and the like to get around this and know when they have to do so, or better even know when a file isn't actually located where it seems to be. Maybe there is (or can be, if the right function is called) now a new flag set when listing files carrying just this information.

Thanks. I'm going on the hunt once I have win7...

[graham]

creat wrote:

To be honest I think this actually makes sense (as long as there is a way to know weather a file is actually located there or in the VirtualStore), even though this may not be the popular point of view. Think of all the problems this solves (viruses infecting executable files in 'program files' and/or the windows folder, to name just one).
The VirtualStore solution is just a necessary way to allow programs to seemingly write there, since a lot of them (like XYplorer, at least by default) keep their settings there. The intended way (at least by Microsoft) to handle per user versus all user settings would be to keep them either in [user directory]\appdata versus [allusers]\appdata (could obviously be changeable . Personally I think it makes sense to separate program files and settings, and this encourages developers to do so. It even creates per-user settings for programs that didn't bother with that option (though programmers have to explicitly care if they want shared settings now).
This is all obviously only valid if there is a way for programs like file managers and the like to get around this and know when they have to do so, or better even know when a file isn't actually located where it seems to be. Maybe there is (or can be, if the right function is called) now a new flag set when listing files carrying just this information.

Thanks for the above explanation - I have just moved onto win7 , x64 and was thinking that XY did not sit easily with win7 for the reasons you mention. Like you, after playing around it does all make a lot of sense from a security aspect and I think it is a good move but it is a move that is not immediately easy to live with. XY works on the basis a disk is full of files and folders to be manipulated whereas it seems the win 7 approach is a disk is full of files and folders but you are not able to directly control any that could cause system problems. The virtulisation is great for users as it 'gathers' data together in a common place. I have had only a brief encounter with win 7 and was 'forced' to set up folders/files in the user area (or appdata) for files that previously 'belonged' in the program folder for an application. It eventually dawned on me after my app just refused to 'see or access' certain files but once those files were put in the user folder all worked correctly. This of course assumes that the application can have settings to re-direct. In my particular application it had user options to set a collection of paths for the app to access support files or it would not have worked! This change is very similar to the old change that happened when My Documents folder first appeared way back, prior to that user data was scattered around most often kept with the application folder.
So, for now I am battling to understand it all but it looks as though it is here to stay and the virtual folders (libraries in win7 speak) are a major step forward in user file access terms.

[admin]

I still don't have W7 but I wonder if here's a possible solution for the original request of the thread: http://msdn.microsoft.com/en-us/library/bb756929.aspx

If I added requireAdministrator via manifest like this:

Code: Select all

  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

... would that change anything in the behavior?

[PeterH]

I thought I'd understand some technical english
I'm afraid there's a lot I don't understand...

But ok - requireAdministrator seems a bit much for me?
Especially, as I sometimes prefer to make file mgmt as a non-administrative user. (More exact: use [runas] administrator only if I think it's neccessary.)

[nas8e9]

I still don't have W7 but I wonder if here's a possible solution for the original request of the thread: http://msdn.microsoft.com/en-us/library/bb756929.aspx

If I added requireAdministrator via manifest like this:

Code: Select all

  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>

... would that change anything in the behavior?

I suspect what this does is to always when starting XYplorer, request elevation. It doesn't "silently" activate; it merely saves the user the trouble of right-clicking on the shortcut and selecting Run as administrator.

(The uiAccess property seems to be described here; it doesn't seem to be relevant.)

[Creat]

If I added requireAdministrator via manifest like this:

Code: Select all

manifest-code

... would that change anything in the behavior?

I'm afraid not, it acts lice as nas8e9 pointed out above. This is intended for applications that actually require elevation to function and won't work at all without it. Everyone can easily set this as an option in the shortcut if they want.