Announcement Announcement Module
Collapse
No announcement yet.
MutliPartFile.getOriginalFilename() full windows path IE Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MutliPartFile.getOriginalFilename() full windows path IE

    I'm using this code to save a MultiPartFile (file) to the filesystem.

    Code:
    file.transferTo(new File("/path/to/dir/" + file.getOriginalFilename()));
    It works fine and saves the file BUT when I use IE to upload the file the filename includes the full local windows path so files are being saved with names like D:\my\files\thefile.gif instead of thefile.gif

    Uploading with Firefox does not have this problem. I know the Javadoc mentions that this may happen in Opera. Has anyone had this problem (and hopefully solved it) before?

    Thanks
    Steve

  • #2
    I usually do something like the following:
    Code:
    File f = new File(file.getOriginalFilename());
    String fname = f.getName();
    file.transferTo(new File("/path/to/dir/" + fname));
    Hope this helps,
    F.

    Comment


    • #3
      Thanks Fernando, tried it but I'm afraid it still seems to do the same thing. I guess I'm just going to have to check the getOriginalFilename() string for \s before I use it. Something like...

      Code:
      String filename = file.getOriginalFilename();
      
      if (filename.indexOf("\")!=-1)
          // trim out the windows file path...
      }

      Comment


      • #4
        Oh, I think I see where my error is.

        Most likely you are using some non-Windows platform at the server side. Since File specifications are not portable across platforms, the server-side created java.io.File is not being able to extract the name from the supplied client-side Windows path.

        Yes, I'm afraid you'll have to write the code to extract the name... now I'll go back to correct my own code :wink: !

        Rgds,
        F.

        Comment


        • #5
          OK! Thanks for your help

          Comment


          • #6
            I think this is due to a pretty well known bug in commons-fileupload, which can't handle the situation where the client is a different OS than the server.

            This is described to some extent in this Tapestry bug database entry:

            http://issues.apache.org/bugzilla/show_bug.cgi?id=27544

            Regards,

            Comment


            • #7
              I've just added added special parsing of original filenames to Spring's CommonsMultipartFile, detecting both Unix- and Windows-style paths. It's trivial to do, and Commons FileUpload still doesn't seem to fix this itself.

              Juergen

              Comment

              Working...
              X