CreateDirectory() - Could not find a part of the path "D:\".

[Guest]

Hi,

On a Windows 2000 Server when attempting to use
System.IO.Directory.CreateDirectory(string.concat(Server.MapPath(""),
"\verify"))
I receive a System.IO.DirectoryNotFoundException error: Could not find a
part of the path "D:\".

The full path is "D:\hshome\clinton\test.gotchasoft.com\verify"
The web is running using impersonation as a user on the local machine.
The user has no access to d:\, d:\hshome, or d:\hshome\clinton.
The user has modify access to d:\hshome\clinton\test.gotchasoft.com.

Using the old Scripting.FileSystemObject.CreateFolder() using the same path
name works fine.
System.IO.Directory.DeleteDirectory() using the same path once created works
fine.
System.IO.Directory.SetCurrentDirectory(server.mappath("")) raises a similar
error but lists the entire folder structure rather than just the root.

I've seen similar posts accross the web, and have tried the following
suggestions:
Granting the "Bypass traverse checking" right to Everyone had no effect;
Granting the "Read Extended Attributes" to the D:\ drive had no effect.

This error is confirmed accross 38 Windows 2000 servers in an H-Sphere
(psoft.net) cluster, all with .NET Framework v1.1 installed.

Any help would be appreciated!

Clinton Frankland

 

[Steven Cheng[MSFT]]

Hi Clinton,

Welcome to ASP.NET newsgroup.
From your description, when you're using Directory.CreateDirectory to
create sub dirs through the path retrieved by the Server.MapPath("") , you
got
========
System.IO.DirectoryNotFoundException error: Could not find a part of the
path "D:\".
========

error. Also, you're suffering the problem on many other machines with the
same environement, yes?

Based on my loal test and the code sinppet, the problem is likely caused by
something with your environment. Would you help me confirm the following
things:

1. Does the problem occurs if you directly pass the full physical Path of
your application's virtual dir to the CreateDirectory function?

2. If still occurs, we may do some check on permission. How about turn off
impersonate and use the default process identity(should be machine\aspnet
for win2k server) and grant "modify/write" permission to that account. Test
again to see whether that can work. ( You can also test creating directory
through passing full qualified path when you swtich the process identity
and turn off impersonate).

BTW, to get the physical path of the root dir of our ASP.NET application,
we can use the
Server.MapPath("~/"), this will be better than using the empty string which
only retrieve the relative path the current directory.

Please feel free to let me know if you got any new findings or need any
further help. Thanks,


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Yes, the all the machines in the same environment have the same problem.

If I pass the full physical path the problem still occurs. Even testing
using the full string
Directory.CreateDirectory("D:\hshome\clinton\test.gotchasoft.com\verify")
fails with the same error message.

This problem originally started using the default aspnet user (which again
did not have read access to the d:\ folder).

If I grant read access to d:\, d:\hshome, and d:\hshome\clinton; the problem
goes away.

 

[Steven Cheng[MSFT]]

Hi Clinton,

Thanks for your response. I think read access is necessary not only for the
application's virtual dir but also for the parent and root dir. This is
because the ASP.NET runtime will need to do monitoring on appliation's dir
and also parent dir (such as monitor the changing of web.config in all the
up level folders). Though I'm not sure this is the direct cause, but I'm
sure the read access must be granted to your asp.net 's executing account.

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

I have just finished troubleshooting the same issue on one of our sites.
This concerns me for two reasons:

1) Misleading Exception thrown

Since the issue is caused by lack of permission for the ASPNET acct. to read
the parent folders, I would expect an UnauthorizedAccessException, not
DirectoryNotFoundException.

2) Non-standard behavior of permissions

If I create C:\PermTest\ and C:\PermTest\user then grant full rights to the
\user folder and no read permission to C:\PermTest. I can view and create
folders, files, etc. in C:\PermTest\user, but cannot view anything in
C:\PermTest. (Tested using a windows login acct. not the ASPNET acct.)

I would expect this same behavior with Directory.CreateDirectory.

Insight from other developers implies that the CreateDirectory function's
behavior of creating a full path, not just the last directory in the given
path, is what is causing this. If it tries to look in C:\ (or D:\) to see if
the folder exists and is denied read access, then it appears to be failing
the CreateDirectory funciton entirely. For a good example see
http://hatka.net/wlogdev/archive/2004/08/29/178.aspx

Maybe a good solution would be two functions? CreateDirectory(string path) -
behaving this exact way for backwards compat. and CreateDirectory(string
path, CreateDirectoryBehavior.LastDirectoryOnly); or something to that affect.

Bryan Gerber
ASP.NET Developer

 

[Guest]

I just got done troubleshooting this error on one of our web applications.
There is a good source for this error and a good possible explanation at
http://hatka.net/wlogdev/archive/2004/08/29/178.aspx

This behavior concerns me for two reasons:

1) Wrong exception thrown

If the error is due to a lack of permission, UnauthorizedAccessException
should be thrown, NOT DirectoryNotFoundException

2) non-standard permission behavior

If I create a new windows login and the following folders:

C:\PermTest\
C:\PermTest\user

Granting full perms to new user on \user folder and no perms on C:\PermTest,
the user CAN write files and create directories in C:\PermTest\user, but
cannot read anything in C:\PermTest.


If I were fixing this, I might overload the CreateDirectory function to
support both behaviors:
CreateDirectory(string path) could remain as is
CreateDirectory(string path, CreateDirectoryBehavior.CreateLastOnly) could
ignore the first part of the path and just create the final folder in the
path string.

At the very least, I think that the MSDN documentation for
Directory.CreateDirectory should explicity mention this behavior at the top
of the page instead of implying it in the remarks section.

 

[Guest]

Sorry for double post. Apparently, the post page lied to me when it said
there was an error posting my first message.

 

[john.crim]

I had the same problem ("DirectoryNotFoundException - Could not find a
part of the path"), and found the remedy. If you search around, you'll
find that whenever this problem occurs, it's when someone is using a
drive other than C: - and usually these are locked down drives.

Apparently, Directory.CreateDirectory() requires read and list contents
permissions on the root of the drive where the directory is being
created. The fix for me was to copy the permissions that I found on
the root of my C: drive to the root of my F: ( could be D:, etc) drive.

There is one permission set for Everyone on the C: drive, for "this
folder only" (not inherited), that gives Read & Execute permissions.
When I reproduced that permission set on my F: drive, this problem went
away. An important point is that by making this permission not
inherited into child folders and files, I don't have to worry about
opening up a big security hole.

Hope that helps,
John Crim
WebRelevance, Inc.

 

[john_crim]

Dangit!!! I didn't think Google groups would post my email address....

 

[john_crim]

I had the same problem ("DirectoryNotFoundException - Could not find a
part of the path"), and discovered the fix. If you search around,
you'll
find that whenever this problem occurs, it's when someone is using a
drive other than C: - and usually these are locked down drives.

Apparently, Directory.CreateDirectory() requires read and list contents

permissions on the root of the drive where the directory is being
created. The fix for me was to copy the permissions that I found on
the root of my C: drive to the root of my F: ( could be D:, etc) drive.


There is one permission set for Everyone on the C: drive, for "this
folder only" (not inherited), that gives Read & Execute permissions.
When I reproduced that permission set on my F: drive, this problem went

away. An important point is that by making this permission not
inherited into child folders and files, I don't have to worry about
opening up a big security hole.


Hope that helps,
John Crim
WebRelevance, Inc.