From commons-dev-return-28132-qmlist-jakarta-archive-commons-dev=nagoya.apache.org@jakarta.apache.org Thu Apr 24 07:28:11 2003 Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 33644 invoked from network); 24 Apr 2003 07:28:10 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 24 Apr 2003 07:28:10 -0000 Received: (qmail 4083 invoked by uid 97); 24 Apr 2003 07:30:18 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org Received: (qmail 4076 invoked from network); 24 Apr 2003 07:30:18 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 24 Apr 2003 07:30:18 -0000 Received: (qmail 33467 invoked by uid 500); 24 Apr 2003 07:28:08 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 33446 invoked from network); 24 Apr 2003 07:28:07 -0000 Received: from unknown (HELO besec550.swift.com) (195.99.94.5) by daedalus.apache.org with SMTP; 24 Apr 2003 07:28:07 -0000 Received: by besec550.swift.com with ESMTP id h3O7F3Bw020167 for ; Thu, 24 Apr 2003 07:15:03 GMT Date: Thu, 24 Apr 2003 09:28:09 +0200 From: DE LEEUW Thierry Subject: [FileUpload] questions and remarks. To: commons-dev@jakarta.apache.org Message-id: <3EA79209.84B6969B@swift.com> Organization: S.W.I.F.T. sc MIME-version: 1.0 X-Mailer: Mozilla 4.79 [en]C-CCK-MCD SWIFT-W74 (WinNT; U) Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_pIagkjd6sFAIzPo6tNzteQ)" X-Accept-Language: en X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --Boundary_(ID_pIagkjd6sFAIzPo6tNzteQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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. * 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 ). Best regards, Thierry De Leeuw --Boundary_(ID_pIagkjd6sFAIzPo6tNzteQ)--