Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
To: commons-user@jakarta.apache.org
From: "Martin Cooper" <martinc@apache.org>
Subject: Re: [FileUpload] The getName method yields inconsist value
Date: Tue, 6 May 2003 15:53:29 -0700
Lines: 115
Message-ID: <b99eam$tck$1@main.gmane.org>
References: <oprop4o8sxvu4si3@mail.bluesoft.ca> <b96vpl$hgt$1@main.gmane.org>
 <oproqft8mhvu4si3@mail.bluesoft.ca> <20030506074751.I69559@icarus.apache.org>
 <oproru03ozvu4si3@mail.bluesoft.ca>
Sender: news <news@main.gmane.org>


"Vernon" <vernonw@gatewaytech.com> wrote in message
news:oproru03ozvu4si3@mail.bluesoft.ca...
> On Tue, 6 May 2003 07:54:10 -0700 (PDT), Martin Cooper
<martinc@apache.org>
> 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
container
> > 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.

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

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("java.io.tmpdir");
File dataStore = new File(systemTempDir, "VernonsDataStore");
String fileName = "SomeFileName.dat";
File outputFile = new File(dataStore, fileName);
item.write(outputFile);

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
DiskFileUpload.

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
need.

--
Martin Cooper


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