commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: [FileUpload] The getName method yields inconsist value
Date Tue, 06 May 2003 22:53:29 GMT

"Vernon" <> wrote in message
> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
> wrote:
> >> > If you had this before:
> >> >
> >> > String newFile = "C:\\temp\\upload.dat";
> >> > item.write(newFile);
> >> >
> >> > you would just do this now:
> >> >
> >> > File newFile = new File("C:\\temp\\upload.dat");
> >> > item.write(newFile);
> >> >
> >> > Passing a File to write() allows you to do the same as you would have
> >> > done
> >> > before, but it also allows you to work with paths and files without
> >> > having
> >> > to mess with separators, amongst other things.
> >> >
> >>
> >> So what is the reason(s) the write(String) API is deprecated? It is
> >> discouraged to use a deprecated method, is it? Also, it is difficult to
> >> use
> >> the write(File) method if the getName() method only return a file name
> >> only, but not its full path.
> >
> > Yes, the use of deprecated methods is discouraged, because those methods
> > will go away in a later release (in this case, RC1). I deprecated the
> > write(String) method because you can accomplish the same thing - and a
> > lot
> > more - with write(File).
> >
> > You absolutely should *not* be using the path provided by getName() to
> > pass to write(). That path is the one to the original file, on the
> > browser
> > user's system, ans bears no relationship to the file system the
> > is using. Attempting to use this path would be *very* dangerous.
> >
> > This looks like an excellent reason to remove the write(String) method.
> > ;-)
> >
> So, how to create a file instance as you stated above without a file path
> information? It isn't a method of FileItem returning a file full path.

OK, let's go back to basics. Once you have parsed the upload, you are
iterating over the file items and you come across a file upload. You want to
copy/move the uploaded data to some more permanent location, so you need to
call write() with a File instance.

You create the File instance the same way you would create an output file
for any other file i/o operation. I gave an example in an earlier message in
this thread, but using a single fully qualified path (see above). But for
another example, let's suppose that you have some data store that you want
to move the uploaded file to. Just for the sake of the example we'll
construct a File for that directory, and then make up a name for the new

File dataStore = new File("X:\\VernonsDataStore\\");
String fileName = "SomeFileName.dat";
File outputFile = new File(dataStore, fileName);

I've expanded this for the sake of illustration, but you can do this however
you want. If you wanted your data store to be in a subdirectory of the
system temp directory you could do this:

String systemTempDir = System.getProperty("");
File dataStore = new File(systemTempDir, "VernonsDataStore");
String fileName = "SomeFileName.dat";
File outputFile = new File(dataStore, fileName);

This is just the normal usage of File objects for file i/o - there's nothing
special about it because it's an uploaded file.

If all you wanted to do was access the uploaded data, of course, you would
just use getInputStream() and process it however you want.

If there is some reason you need to access the original temp file created by
FileUpload, and you are using DiskFileUpload, and you are not supplying your
own factory, then you can do this:

File originalUpload = ((DefaultFileItem)item).getStoreLocation();

but there is no good reason to do this when you can use write() or
getInputStream() instead, and be free of the implementation details of

If you haven't done so already, I recommend you take a look at the new
documentation on the FileUpload web site. It should cover everything you

Martin Cooper

> > --
> > Martin Cooper
> >
> Vernon
> -- 
> Vernon

View raw message