Grails 3.2 文件上传错误 (FileNotFoundException )

Question

I'm trying to run a Grails 3.2 web application with Tomcat 8 on Windows 10 that involves file upload. The webApp launches correctly but when I try to upload any file remotely I keep getting the file error below. Notice in the message there are two absolute paths jammed together, which would make for an invalid file specification. I do not get this error when I access the application inside the host machine using localhost as the IP address. Any help is appreciated.

<g:uploadForm name="sstForm" controller="sstSetup" method="POST" >
    <input id="w-mdf" type="file" name="wMDF" />&nbsp;&nbsp;

    <div class="yui3-u-25-100" id="setup-submit">
        <g:actionSubmit class="input block-page" name="submit" value="Submit" action="setupAction" onclick="return validateInput();"/>
        <g:actionSubmit class="inputGrey block-page" name="cancel" value="Cancel" action="cancel"/>
    </div>
</g:uploadForm>

Then on the server side I grab the MultiPart file object in the controller and call tranferTo to convert it to a normal file

File fileDest = new File("Path to some destination and file name")

multipartFile.transferTo(fileDest)

Nothing complicated here. Yet it is throwing FileNotFoundException when the upload is coming from a remote location.

Error: java.io.FileNotFoundException: D:\\Users\\RWSK70\\Documents\\Clark\\CIM\\Misc\\Drools\\DroolsIntelliJProject\\drools-app\\target\\classes\\rules\\C:\\Users\\RWSK70\\Documents\\Clark\\!!\\CIM\\Misc\\Drools\\DroolsIntelliJProject\\drools-app\\src\\rules\\application\\1233275_RSF_v243.txt (The filename, directory name, or volume label syntax is incorrect)

Answer 1

I found the Issue. It was caused by the way I handled the uploaded Multipart file. The Servlet specification gave clients the leeway to return either the filename or the absolute path of the file when multipart.getOriginalFilename() is called. I made the erroneous assumption that clients will always return the simple filename based on experience. This is a wrong assumption. It turned out that in this one production environment, their browsers were sending the absolute path of the file instead of the simple filename which the application was expecting and that did not go well. – Felix Andrews Dec 2 at 18:53