Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: RE: [PATH]FileUpload fix for filename for msiexplorer
From: maciek <maciek@pb-network.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPMECMCIAB.noel@devtech.com>
References: <NBBBJGEAGJAKLIDBKJOPMECMCIAB.noel@devtech.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 28 Jun 2003 16:46:51 -0400
Message-Id: <1056833211.12974.28.camel@bluephant>
Mime-Version: 1.0

My problem came out when I was working on an administration module with
the ability to upload files to client's directory on a linux server, to
be more specific mostly images to be displayed on a client's web site.
FileUpload component when used with netscape uploaded only the file
which was what I wanted, but with MSIE the whole path was saved as, for
example : /home/clientA/C:\Documents\myImages\test.jpg and was not
usable. Then I tested for user-agent in a jsp file and parse a return
String from getName() accordingly stripping the path info if it was MSIE
client.This quick/simplistic and not robust solution worked for my
administration module requirements and
I do understand that there may not be the need to implement this
functionality in the component like Martin Cooper explained making a
strong point for it and leave it to web developers and their
applications requirements.
Regards,
maciej
ps.I would like to thank everybody for valuable insights so far to help
me look at the issue from different points of view.


On Sat, 2003-06-28 at 16:05, Noel J. Bergman wrote:
> > FileUpload should not be in the business of deciding, on behalf of its
> > client, how to interpret the content of fields uploaded by the browser.
> 
> +1
> 
> > > Method getName() in DefaultFileItem.java class when used with
> > > msiexplorer 5/6 returns a filename with the whole client's
> > > filesystem path which creates a problem when you want to save
> > > the file on a server's filesystem.
> 
> What if I were storing information in a database, and wanted to preserve the
> client's fields, or had some other need for the path?
> 
> What guarantee is there that the filename, even without the path, is valid
> for the server?  What if the client OS uses a different set of allowable
> symbols?  What if I already have a file of that name from another user?
> What if ... ?  Simply stripping the path from the name isn't going to
> address the problem.
> 
> Besides which, this functionality is already in java.io.File:
> 
>   import java.io.File;
>   public class filename {
>       public static void main(String[] args) {
>           System.out.println(new File(args[0]).getPath());
>           System.out.println(new File(args[0]).getParent());
>           System.out.println(new File(args[0]).getName());
>       }
>   }
> 
>   $ /usr/local/java/bin/java -cp . filename "~noel/filename.java"
>   ~noel/filename.java
>   ~noel
>   filename.java
>   $ /usr/local/java/bin/java -cp . filename "c:/frodo/filename.java"
>   c:/frodo/filename.java
>   c:/frodo
>   filename.java
>   $ /usr/local/java/bin/java -cp . filename "share:/frodo/filename.java"
>   share:/frodo/filename.java
>   share:/frodo
>   filename.java
>   $ /usr/local/java/bin/java -cp . filename
> "//myserve/share/frodo/filename.java"
>   /myserve/share/frodo/filename.java
>   /myserve/share/frodo
>   filename.java
>   $ /usr/local/java/bin/java -cp . filename
> "\\myserve/share/frodo/filename.java"
>   \myserve/share/frodo/filename.java
>   \myserve/share/frodo
>   filename.java
> 
> OK, so java.io.File has some issues with UNC names on linux.  Let's check
> Windows:
> 
>   > java -cp . filename "//myserve/share/frodo/filename.java"
>   \\myserve\share\frodo\filename.java
>   \\myserve\share\frodo
>   filename.java
> 
>   > java -cp . filename "\\myserve\share\frodo\filename.java"
>   \\myserve\share\frodo\filename.java
>   \\myserve\share\frodo
>   filename.java
> 
> Works fine.
> 
> 	--- Noel
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org