commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Leland <>
Subject Re: [FileUpload] questions and remarks.
Date Thu, 24 Apr 2003 14:31:31 GMT

   Thanks, these are all good points, and come at a good time as the
  [fileupload] committers are pushing towards a 1.0 release. Opening a
   Buzilla report so the [fileupload] committers can address these items,
  is the best way to go for [fileupload]. Other commons components are
   not as formal, but I know we certainly want to address most/all of
  these points before the 1.0 release.

DE LEEUW Thierry wrote:
> Hello,
> I've a few questions/remarks regarding the file upload (and mainly around DefaultFileItem).
>    * the example should be updated because String fileName = fi.getFileName(); has been
replaced by String fileName = fi.getName();
>    * I expected the setSizeThreshold option to work on the file size and not the request
size but it's a valid approach, I was
>      simply confused by     the statement "Sets the size threshold beyond which files
are written directly to disk." from the
>      JavaDoc.

I haven't looked at this but for multiple file uploads then the docs 
would be very misleading.

>    * the "delete" function is not working properly (at least at my side with NT 4 and
J2SDK 1.4.1_01 from NetBeans 1.4). The
>      temporary files     stays in the folder. I will try to investigate if the file is
still in use somewhere else.

>    * the way "write()" is implemented looks a bit dangerous to me. File.renameTo currently
seems to not update the "internal" file
>      name. So your     original file is "/tmp/upload_00000000.tmp", after the renameTo("/usr/test.jar")
the File object still
>      contains "/tmp/upload_00000000.tmp"     (which I'm not sure it is valid, I would
expect to "follow" the file. But this is Sun
>      implementation).
>               if (storeLocation != null && storeLocation.exists()) {
>                    storeLocation.delete();
>               }
>      This means that if Sun decide to change their implementation and the way RenameTo
works (to "follow" the underlying file), you
>      will          actually delete the file that the user tried to save. It also means
that you can call (with the current Sun
>      implementation) write() method          only once. If Sun changes the implementation,
you will be able to call it more than
>      once but then you will only have one copy of the          file (where I would expect
to have multiple copies).
> If you agree, I would be pleased to contribute to your project (by implementing the changes
I suggested (and maybe others) after
> your agreement
> ).

Patches are certainly allways welcome !

> Best regards,
> Thierry De Leeuw

Thanks again !

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message