File upload create a file in /tmp - java

When using a form that uploads a file to my Play! Framework application, a file is created in ${application_path}/tmp/ with an unique ID like :
0851e44f-8d7e-4afd-8edf-3d9bd6c909c9
and contains all the data sended by the form (POST & FILES)
I located the creation of this file in :
play.server.StreamChunkAggregator.java:51
But I don't know why this file is not removed when the request is finished.
Is there any reason that the file isn't removed? is it specific to Play (1.2)?

The file should be removed automatically at the end of the request, so something unusual must be going wrong.

Isn't it the classical way of Server API to manage upload files?
Why they are not deleted ? I don't know but I see the same kind of behavior in Tomcat...

Related

Java Servlet 3.0 File Upload - Removing TMP Files

I'm using the Java Servlet 3.0 to upload files, using the #MultipartConfig annotation and request.getParts() to obtain the files.
When a file is uploaded, a TMP file is created in the Web Application work directory (tomcat/work/Catalina/localhost/webappname). For example:
upload_7c59101b_9f97_4e3f_9fa5_e484056d26fa_00000209.tmp
The application copies the file to another directory on the server - I'm doing this using the part.write() method but it's also working by obtaining the input stream and writing the bytes. Either way works fine.
I need to remove the TMP files after the upload, but I'm having trouble doing so. The part.delete() method doesn't do anything. I've also tried accessing the files in the directory using javax.servlet.context.tempdir and iterating over them to delete, but when calling a delete method, it always returns false. Using the Files.delete(path) method from Files.nio returns an exception which claims the file is in use by another program (i.e. locked) and therefore cannot be deleted. The server is running Windows Server 2012 R2.
Does anyone have any other solutions to remove these TMP files? It's worth pointing out that I've tried using a HttpRequestListener too, but still cannot delete the files.
Many thanks
You should (must!) not manipulate the files directly, you should use the getInputStream() method of the particular Part to get the content of the uploaded file. The servlet container (Tomcat in your case) will - or at least should - take care of the temporary files.
Along with InputStream.close(), use Part.delete() to remove the stored temporary file under work directory. Please refer the javadoc: Part.delete().
I agree with Jozef Chocholacek answer, simple solution CLOSE the input.
We were using MultiPart messages with files upload.
Since we were not closing the inputStream the files were stored there for a loooong time. They were deleted only on server restart.
After slightly changing the implementation with always closing the input part at the end.
Use try-> catch-> finally and put closing in finally part which will be
called always even when the call of method fails.
The server is not storing .tmp files anymore.

How do I UPDATE (not add an additional) attachment in Atlassian Confluence with their Java API?

We have a custom plug-in that allows people to upload documents through the GUI, and add metadata about those documents within our plug-in. Also, another function of the plug-in, is we have an XML file being pushed to us via the Confluence SOAP service. This XML file is being attached to a specific file within the plug-in space, by the SOAP service, once a day.
We have now been charged with turning the process around. We will now make our own SOAP call to get the same XML file and attach it to the same page.
I can successfully attach a new file to the page, but when I try to update (replace) that XML file with a newer version, I end up uploading another file, so I am left with multiple copies of the file with the same name, which is not what we want.
Here is what I have that adds a new attachment, but does not update (replace) the attachment:
page = pageManager.getPage(spaceKey, pageTitle);
attachment = attachmentManager.getAttachment(page, attachmentFilename);
Attachment currentAttachment = null;
currentAttachment = (Attachment) attachment.clone();
attachment = new Attachment();
attachment.setFileName(attachmentFilename);
attachment.setContent(page);
attachment.setFileSize(fileSize);
attachment.setContentType(newAttachmentContentType);
attachment.setCreator(page.getCreator());
attachment.setCreationDate(date);
attachment.setComment(attachmentComment);
attachmentManager.saveAttachment(attachment, currentAttachment, dplAsStream);
Again, what I want is to replace filename.xml with an updated filename.xml, but what I am getting is filename.xml, filename.xml, filename.xml, etc.
As far as I know there is no simple updateAttachment since the file storage follows a version-based approach. Every upload of the same file (by its filename) will be a newer version of the already present file without removing the older one.
To implement your update functionality it might be necessary to do multiple steps:
Check if the file to be uploaded already exists (=update)
Remove a given version or all previous versions using the AttachmentManager
Upload the file
Maybe the CLI implementation gives some more details how they made it because here you can run an update command.

upload file using servlet but in run time only

I need to upload file to my web application using servlet, the problem is that I want the file to be available only in the run time !
I know to upload the file to the server, but I need the file to be available when the user upload the file to the web and do some tasks to the file and when he close the web application he will lose the file and need to upload it again
Would you please give me any tutorial to help me?
I think what you need is a javax.servlet.http.HttpSessionListenerthat delete the file when the user session is destroyed (see method sessionDestroyed(HttpSessionEvent se))
Hope it helps.

GWT - Client-Side File Uploads

I have been messing around with GWT uploads lately. I want to have the ability to upload an XML file from the client, and get the contents of that file (display the contents in a TextArea).
From what I have found on the net, it seems I would have to upload the file to the server, and then get the contents of the file. I do not particularly like the idea of allowing file uploads to the server (even if they are only XML). Is there anyway to pull the contents of a file that the client specifies without sending it to the server?
Thanks
Recent (decent?) browsers implement the "HTML5" File API that's quite easy to use in GWT using JSNI.
See also: https://developer.mozilla.org/en/Using_files_from_web_applications
Because of security restrictions you cannot access the file on the client side alone. It has to be sent to the server for processing.

Zip File on a web server to extract in to local machine

We have a web application that allows user to download a zip file from a web server. We just provide dummy iframe source to the full URL of zip file on web server. This approach would allow end user to use browser controls which allows the user to open or save the zip to user's local machine.
We have a requirement that the zip file is automatically extracted and save to a specific location on user's machine. Any thoughts on how this can be achieved?
Thanks.
I highly doubt that you'll be able to do that. The closest you're likely to get is to generate a self-extracting executable file (which would be OS-dependent, of course).
I certainly wouldn't want a zip file to be automatically extracted - and I wouldn't want my browser to be able to force that decision upon me.
Short answer is I don't believe this is possible using the simple URL link you've implemented.
Fundamentally the problem you have is that you have no control over what the user does on their end, since you've ceded control to the browser.
If you do want to do this, then you'll need some client-side code that downloads the zipfile and unzips it.
I suspect Java is the way to go for this - Javascript and Flash both have problems writing files to the local drive. Of course if you want to be Windows only then a COM object could work.
Instead of sending a zip file why don't u instruct the web server to compress all the web traffic and just send the files directly?
See http://articles.sitepoint.com/article/web-output-mod_gzip-apache# for example.

Categories