commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vernon <vern...@gatewaytech.com>
Subject Re: [FileUpload] The getName method yields inconsist value
Date Tue, 06 May 2003 22:20:53 GMT
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.

> --
> Martin Cooper
>

Vernon



-- 
Vernon

Mime
View raw message