Could not find a part of the path

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Environment: Windows 2003 Server R2
Application type: ASP.NET application

sample code:
string filePath variable = "c:\xyz\abc";
FileStream clientFilew = new FileStream(filePath, FileMode.Create); //blows
here

Error message:
Could not find a part of the path.

Now, the filePath variable = "c:\xyz\abc" MOST CERTAINLY EXISTS on the web
server.
"Everyone" user has FULL ACCESS to the C: drive.
"Everyone" user has FULL ACCESS to the C:\xyz folder.
"Everyone" user has FULL ACCESS to the C:\xyz\abc folder.

I already tried just having "NETWORK USER" have access to the same
things...no dice.

This is incredibly frustrating as this works with no issue on my development
machine. Based upon the "Everyone" settings, I can't imagine this is STILL
an authorization issue of the .net environment not being able to create a
file in the specified folder ???
Could the error message be any more ambiguous or incorrect?
Thanks in advance for any insight into this most enlightening error message.
Larry
 
Hello,

one way to troubleshoot this is NTFilemon from Microsoft (formerly
Sysinternals). With that tool you'll see if this is an access deny error.

Best regards,
Henning Krause
 
Actually,
string filePath variable = "c:\xyz\abc\myfile.pdf";
Sorry for the confusion.
Larry
 
Hello Larry,

As for the code snippet you provided:

==========
string filePath variable = "c:\xyz\abc";
FileStream clientFilew = new FileStream(filePath, FileMode.Create); //blows
==========

are you using .net C# language and is the above the exact code you used in
the application?

If so, I think the problem is likely due to the character escapting of the
"\" char, this is a special character that need to be escapted in C#
string. so your code should be like either one below:

string filePath variable = "c:\\xyz\\abc\\filename.ext";
FileStream clientFilew = new FileStream(filePath, FileMode.Create);

or

string filePath variable = @"c:\xyz\abc\filename.ext";
FileStream clientFilew = new FileStream(filePath, FileMode.Create);

If there is anything I missed or if you have any further finding, please
feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Thanks for the reply.

No, this is pseudo-code c#.
It works in development, so if it was a simple problem as you suggest, it
would not work in development either.
I'll try the suggestion posted by someone else to use Filemon... and see if
it is a file naming issue, or access denied problem.
Larry
 
Thanks for your reply Larry,

Thus, there must be something else cause the issue. BTW, for permission
issue, you can consider swtich the application to running under some
interactive user accounts for test. Please feel free to followup if got any
further progress or if there is anything we can help.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello Larry,

Have you got any further progress on this issue, or did you further narry
down the access permission point? If there is anything else we can help,
please feel free to post here. Or if you still have no luck or feel it
urgent to resolve the issue, you can consider contact CSS for further
assistance.

http://msdn.microsoft.com/subscriptions/support/default.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.
 
The issue has been resolved. It's a bit difficult to explain, so I'll
summarize. The issue was not an actual authentication issue at all. It
turns out that my "Click Once", or "Zero Deployment" application was pointing
to a Web Service on the wrong machine. So, the error was being generated
from a completely different machine. It turns out this is actually a bug in
the "Click Once" function in Visual Studio. If one uses the option to place
".Deploy" at the end of every published file, then the application cannot
location the app.config file and thus the URL for the web service cannot be
loaded from that file (and thus the development URL continues to be used).
The suggestion to use the FileMon.exe was what helped me get to the bottom of
this. Thanks to Henning Krause.
Larry
 
Back
Top