|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Creating directories on Vista machines using .NETI've noticed that simple .NET code to create directories does not seem to work on Vista. Take the following simple example (implemented in a Windows forms application): ========================== FileInfo executableFile = new FileInfo(Application.ExecutablePath); DirectoryInfo directory = executableFile.Directory.CreateSubdirectory("Test"); if (!directory.Exists) { directory.Create(); } ========================== This works fine on XP, but not on Vista, despite the “belt and braces†approach! I guess this is to do with the improved security model in Vista. Clearly there will be no way to override this in code (else it is useless in preventing hackers from playing), but it would be good to find some kind of solution to this problem, even if that was popping up a box for the user to confirm that they’re happy for Vista to perform the action. Does anyone have any ideas as to how I can proceed? Thanks in advance, Steve. Even in XP, AFAIK you can't create a directory in "program files" (is this
where your executable is ?) under a non administrative account. Depending on what you are trying to store, I would rather try another location... Else what is the error you get ? "Steve Barker" <stevebarker@nospam.nospam> a écrit dans le message de news: FC7E57C4-0FED-400F-A0D4-784E66E59***@microsoft.com...Show quote > Hi guys, > > I've noticed that simple .NET code to create directories does not seem to > work on Vista. > > Take the following simple example (implemented in a Windows forms > application): > > ========================== > > FileInfo executableFile = new FileInfo(Application.ExecutablePath); > DirectoryInfo directory = > executableFile.Directory.CreateSubdirectory("Test"); > > if (!directory.Exists) > { > directory.Create(); > } > > ========================== > > This works fine on XP, but not on Vista, despite the "belt and braces" > approach! > > I guess this is to do with the improved security model in Vista. Clearly > there will be no way to override this in code (else it is useless in > preventing hackers from playing), but it would be good to find some kind > of > solution to this problem, even if that was popping up a box for the user > to > confirm that they're happy for Vista to perform the action. > > Does anyone have any ideas as to how I can proceed? > > Thanks in advance, > > Steve. > Hi Patrice,
Thanks for your reply! I didn't realise that you don't intrinsically get create permissions on Program File folders if you're not an administrator. Just goes to show that almost all users run Windows under an administrator account all the time. No wonder viruses are so prevalent! Under Vista, when you try to create folders under the Program Files, you don’t get an error. The application continues as though everything is fine, except the folder is not created. This is the case even when you’re logged in as an administrator. However, you can get round this by "running the program as an administrator". To do this, you must find the executable you are trying to run (because the option isn’t available from the shortcut), and right click. The option is something like “Run as administrator…†In that case, the application is able to create the folder. If you're already logged on as an administrator, the thing just works. Otherwise, a dialog appears for you to enter administrator login information. XP is a different matter. When you log in as an administrator, the folder is created with no problems. However, when you log in as a standard user, you get a nasty .NET unhandled exception when you try to create the folder. Has anyone got any suggestions as to how I can make my application more elegant? I am aware of Permission classes in .NET; in this case, the one I need is FileIOPermission. However, I’m not exactly sure what this can do or what the best way to use them would be. Surely, the Assert() method won’t actually give the application the permissions it needs?! Thanks in advance, Steve. Show quote "Patrice" wrote: > Even in XP, AFAIK you can't create a directory in "program files" (is this > where your executable is ?) under a non administrative account. Depending on > what you are trying to store, I would rather try another location... > > Else what is the error you get ? > > > "Steve Barker" <stevebarker@nospam.nospam> a écrit dans le message de news: > FC7E57C4-0FED-400F-A0D4-784E66E59***@microsoft.com... > > Hi guys, > > > > I've noticed that simple .NET code to create directories does not seem to > > work on Vista. > > > > Take the following simple example (implemented in a Windows forms > > application): > > > > ========================== > > > > FileInfo executableFile = new FileInfo(Application.ExecutablePath); > > DirectoryInfo directory = > > executableFile.Directory.CreateSubdirectory("Test"); > > > > if (!directory.Exists) > > { > > directory.Create(); > > } > > > > ========================== > > > > This works fine on XP, but not on Vista, despite the "belt and braces" > > approach! > > > > I guess this is to do with the improved security model in Vista. Clearly > > there will be no way to override this in code (else it is useless in > > preventing hackers from playing), but it would be good to find some kind > > of > > solution to this problem, even if that was popping up a box for the user > > to > > confirm that they're happy for Vista to perform the action. > > > > Does anyone have any ideas as to how I can proceed? > > > > Thanks in advance, > > > > Steve. > > > > > On Fri, 11 May 2007 09:02:00 -0700, Steve Barker
<stevebarker@nospam.nospam> wrote: > [...] Well, setup/installation programs do what you want, so it must be > Has anyone got any suggestions as to how I can make my application more > elegant? I am aware of Permission classes in .NET; in this case, the one > I > need is FileIOPermission. However, I’m not exactly sure what this can do > or > what the best way to use them would be. Surely, the Assert() method won’t > actually give the application the permissions it needs?! possible. :) I haven't used Vista much yet. However, I did read something about it having "virtualization" features for the registry and filesystem for applications that want access to protected areas. So when your application tries to create a directory under Program Files and fails silently, it may be that this virtualization is actually allowing it to succeed but the directory that is created is not in the real Program Files directory. If this is the case, then that application should have an actual "Test" directory that it can use, under Program Files, but you wouldn't see that directory on the disk version of Program Files. Where it actually is, I don't know...I don't recall reading anything about the actual implementation of the virtualization stuff. If you want to create a directory that is actually under Program Files, there is probably some sort of security token thing you can get to allow that, even without explicitly running as administrator. When that happens, a UAC dialog should still come up (if UAC is enabled), and then the "Test" directory should be able to be created in the actual Program Files directory. Note that the above is basically a bunch of hand-waving. I've never actually done that, so I don't have any of the specifics that would be useful in figuring it out. :) But hopefully it gives you some direction for looking into it yourself. Pete Steve Barker wrote:
> Hi Patrice, So when a trusted program checks its directory for plugins, you can't > > Thanks for your reply! > > I didn't realise that you don't intrinsically get create permissions on > Program File folders if you're not an administrator. have another program able to create files in there if it's not trusted. It would be a massive security hole. > Under Vista, when you try to create folders under the Program Files, you The directory is created in > don’t get an error. The application continues as though everything is fine, > except the folder is not created. X:\Users\username\AppData\Local\VirtualStore\Program Files\YourApp When you read the files in Program Files\YourApp the system will first check the VirtualStore for you. Of cause, Microsoft has been saying for almost a decade that you shouldn't write your programs assuming you have access to Program Files unless you know you're running as an administrator, but some developers still don't get it. "Just goes to show that almost all users run Windows under an administrator account all the time. No wonder viruses are so prevalent!" Alun Harford So IMO your best it NOT to write at this location (typically most home
users are running as administrators and so do I but at work I'm running under a non administrative account as all developers should ;-)) Also make sure you don't hardcode the path but use the SpecialFolders constants. Vista and XP doesn't have physically the same location for folders. See http://msdn2.microsoft.com/en-us/library/system.environment.specialfolder(VS.71).aspx and CommonApplicationData lloks like your best bet. Still weird it fails silently (or it could redirect you to some other location making the directory not found when you browse the disk ?). --- Patrice On 11 mai, 18:02, Steve Barker <stevebar...@nospam.nospam> wrote: Show quote > Hi Patrice, > > Thanks for your reply! > > I didn't realise that you don't intrinsically get create permissions on > Program File folders if you're not an administrator. Just goes to show that > almost all users run Windows under an administrator account all the time. No > wonder viruses are so prevalent! > > Under Vista, when you try to create folders under the Program Files, you > don't get an error. The application continues as though everything is fine, > except the folder is not created. This is the case even when you're logged in > as an administrator. However, you can get round this by "running the program > as an administrator". To do this, you must find the executable you are trying > to run (because the option isn't available from the shortcut), and right > click. The option is something like "Run as administrator..." In that case, the > application is able to create the folder. If you're already logged on as an > administrator, the thing just works. Otherwise, a dialog appears for you to > enter administrator login information. > > XP is a different matter. When you log in as an administrator, the folder is > created with no problems. However, when you log in as a standard user, you > get a nasty .NET unhandled exception when you try to create the folder. > > Has anyone got any suggestions as to how I can make my application more > elegant? I am aware of Permission classes in .NET; in this case, the one I > need is FileIOPermission. However, I'm not exactly sure what this can do or > what the best way to use them would be. Surely, the Assert() method won't > actually give the application the permissions it needs?! > > Thanks in advance, > > Steve. > > > > "Patrice" wrote: > > Even in XP, AFAIK you can't create a directory in "program files" (is this > > where your executable is ?) under a non administrative account. Depending on > > what you are trying to store, I would rather try another location... > > > Else what is the error you get ? > > > "Steve Barker" <stevebar...@nospam.nospam> a écrit dans le message de news: > > FC7E57C4-0FED-400F-A0D4-784E66E59***@microsoft.com... > > > Hi guys, > > > > I've noticed that simple .NET code to create directories does not seem to > > > work on Vista. > > > > Take the following simple example (implemented in a Windows forms > > > application): > > > > ========================== > > > > FileInfo executableFile = new FileInfo(Application.ExecutablePath); > > > DirectoryInfo directory = > > > executableFile.Directory.CreateSubdirectory("Test"); > > > > if (!directory.Exists) > > > { > > > directory.Create(); > > > } > > > > ========================== > > > > This works fine on XP, but not on Vista, despite the "belt and braces" > > > approach! > > > > I guess this is to do with the improved security model in Vista. Clearly > > > there will be no way to override this in code (else it is useless in > > > preventing hackers from playing), but it would be good to find some kind > > > of > > > solution to this problem, even if that was popping up a box for the user > > > to > > > confirm that they're happy for Vista to perform the action. > > > > Does anyone have any ideas as to how I can proceed? > > > > Thanks in advance, > > > > Steve.- Masquer le texte des messages précédents - > > - Afficher le texte des messages précédents - Hi Patrice,
Thanks for your feedback. Yes, just as other community members pointed out, your code runs without error because of the virtualization feature of Vista User Account Control(UAC). That is, any write operation to the Program Files directory is redirected to per-user local profile directory. If you are using Windows Explorer to find the file, you will see a "Compatibility Files" button in the toolbar. If you click this button, it will help you to navigate to the redirected folder. The best practise is using Environment.SpecialFolder.ApplicationData to find the per-user application data folder path and save the data there. Please see my original thread below for more information: http://www.thescripts.com/forum/thread638856.html Finally, if you are interested to understand the Vista new UAC security enhancement, I highly recommend "Mark Russinovich"'s online video below, it is almost the best tech talk on UAC topic(level 400): "Windows Vista User Account Control Internals" http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=360 Hope it helps. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. |
|||||||||||||||||||||||