Error:Could not find a part of the path

[E11esar]

Hi there.

I have an ASP.Net form with C# which allows a user to browse to a file and then add the file details to a listbox; I am using a listbox to hold the details for multiple files to enable batch processing.

For each file, I then copy it to a folder called C:\uploads and the file is processed from there.

For the copy command I am using:

File.Copy(listF ileName.Text, importFolder);

and it is here that I receive a message:

Could not find a part of the path 'C:\Uploads\'.

Any ideas how to get passed this please, as I have tried a few ideas from the web but none have been applicable so far?

Thank you.

Mark :)

[Curtis Rutland]

This doesn't make any sense to me....

You say you're using ASP.NET? How are you getting any file details without uploading the file? Unless you are serving the app from the same machine that you are browsing from, you shouldn't be able to browse the user's file system.

Please clarify what you're doing.

[Plater]

The files are on the Clients computer, not on the server computer right?
So when the server executes the SERVER code of File.Copy(), it cannot find these files?

[shweta123]

Hi,

To solve the error you are getting , you can do the following things:

1> You should give the filepath as C:\\upload\\
2> You should specify @ chracter for giving special characters.
e.g FilePath = @(c:\upload\)

[E11esar]

More details

Hi again.

I am using an asp:FileUpload to enable browsing to a folder on the local server (currently my laptop) and then adding the details of

FileUpload1.Pos tedFile.FileNam e

to a ListBox, as I need to load and process multiple files, so this was a best way idea for me to accommodate this requirement.

I then use a foreach on the listbox details and deposit the listbox text details to a File.Copy() command, so for example

listbox.text = "c:\filename.ex t" so this is used in the sourceDirectory part of the Copy command.

I have a constant called importFolder, which is set to "c:\uploads " so the copy is then made up of

File.Copy(sourc eDirectory, importFolder);

I think I can see what maybe going amiss here (as I type this) I am not adding in the fileName to the importFolder, so I need to append this to the directory "c:\uploads "..?

Thank you.

Mark :)

[E11esar]

A bit more

I also have the importFolder defined as

private const string importFolder = @"C:\Uploads \";

Thank you.

M :)

[Plater]

Ok, so do the users ever actually upload the file to you and you write it out to the directory?

For instance:
[code=c#]
string filename = myFileUpload.Fi leName;
byte[] filebytes = myFileUpload.Fi leBytes;
string path = myLogPath;
string pathandfile = path+@"\"+filen ame;
try
{
FileInfo fi = new FileInfo(pathan dfile);
FileStream fs = fi.Open(FileMod e.Create, FileAccess.Writ e);
fs.Write(fileby tes,0,filebytes .Length);
fs.Flush();
fs.Close();
fs.Dispose();
}
catch (Exception ee)
{//todo: log an error??

}
[/code]

[E11esar]

Solved it

Hi again, I have just solved it.

The answer was to append the fileName as mentioned above, hence I used the following code to solve the problem:

foreach (ListItem listFileName in fileList.Items)
{
try
{
.
.
.
string sourcePath = listFileName.Te xt;
string destPath = Path.Combine(im portFolder,Path .GetFileName(li stFileName.Text ));

//Copy file, overwriting if necessary
File.Copy(sourc ePath, destPath, true);
.
.
.

This then has done the trick.

Thank you for your help.

M :)

[Curtis Rutland]

Just to save you this headache later....

This isn't going to work once you start testing it from a real webserver rather than your local machine. The server doesn't have any access to your filesystem, so saying File.Copy or whatever will look on the server's file system not the client's. It's working right now because those are the same; you're browsing from your server.

Remember that all .net code is processed and handled on the server.

[E11esar]

Web server files

Oh that is not good news then..!

Sorry to be a pain but what should I do in this case for when this is running on the server?

Is it best to use the asp.FileUpload and the SaveAs method to save the target file to the uploading directory?

If this is the case then I will be back at square one as I need to process a batch of files and didn't want to add FileUpload's to the web form.

Also to add to this, I am now finding that my current approach is copying across an empty file, whereas the source file is greater than zero bytes..?

Looks like my premature "it is working" was unfounded..!

M :)

[Curtis Rutland]

Well.....ASP.NE T isn't going to be the best way to process multiple files, unless you want to dynamically create multiple FileUpload controls. If it were me...I'd look into using a Silverlight control and a web service. When you "save" files in silverlight, you are actually using local storage on the client's computer. So you can "save" a batch of files locally, and then process them. Write a web service or WCF service that will take a byte[] or maybe a List<byte[]> to do them all at once and do the batch processing, and return a status.

Well, your simple project just got much more complicated :(

[Frinavale]

Well.....ASP.NE T isn't going to be the best way to process multiple files, unless you want to dynamically create multiple FileUpload controls.

This is one of the reasons why most web sites have restrictions on the number of files you can upload.

When you "save" files in silverlight, you are actually using local storage on the client's computer. So you can "save" a batch of files locally, and then process them.

I had no idea that silverlight could do this....
This is a very good excuse to check out silverlight tonight :)

[Plater]

Think of silverlight as a mix between flash and java applets. That's how I look at it.

[Frinavale]

Think of silverlight as a mix between flash and java applets. That's how I look at it.

I don't know about the "Flash" part....
Have you tried using it before?

[Curtis Rutland]

It's a lot like flash in some ways...it's a rich client side plugin. But you really don't program it the same way...it's not on a timeline.

It is more like an applet than anything, but with much less overhead.