Home All Groups Group Topic Archive Search About

Creating directories on Vista machines using .NET

Author
11 May 2007 11:00 AM
Steve Barker
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.

Author
11 May 2007 11:09 AM
Patrice
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.
>
Author
11 May 2007 4:02 PM
Steve Barker
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.
> >
>
>
>
Author
11 May 2007 4:28 PM
Peter Duniho
On Fri, 11 May 2007 09:02:00 -0700, Steve Barker 
<stevebarker@nospam.nospam> wrote:

> [...]
> 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?!

Well, setup/installation programs do what you want, so it must be 
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
Author
11 May 2007 10:26 PM
Alun Harford
Steve Barker wrote:
> 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.

So when a trusted program checks its directory for plugins, you can't
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
> don’t get an error. The application continues as though everything is fine,
> except the folder is not created.

The directory is created in
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
Author
12 May 2007 11:47 AM
Patrice
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 -
Author
14 May 2007 2:53 AM
Jeffrey Tan[MSFT]
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.

AddThis Social Bookmark Button