[fileupload] hi,all,got a delete prob
hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 any secure way to delete the tempotery files? so does any one has solutions ? we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
By the way, your questions are more appropriate for the User list than the Dev list. -- Martin Cooper On 6/7/06, Martin Cooper [EMAIL PROTECTED] wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? -- Martin Cooper we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
Martin Cooper wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. I used FileUpload 1.0 . I am changing to 1.1 :) That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... My code is : DiskFileUpload nDiskFileUpload = new DiskFileUpload(); nDiskFileUpload.setSizeMax(50*1024*1024); nDiskFileUpload.setSizeThreshold(60*1024); i use the java.io.tmp env ( /tmp ) to safe my temptory upload files . List nFileItems = nDiskFileUpload.parseRequest(request); Iterator nIterator1 = nFileItems.iterator(); while(nIterator1.hasNext()){ FileItem nFileItem1 = (FileItem)nIterator1.next(); if(!nFileItem1.isFormField()){ String strFieldName=nFileItem1.getFieldName(); if(!strFieldName.equals(UploadTemp)){ String strFileName=nFileItem1.getName(); String strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName); if(blnGetRepositoryPath){ nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath()); blnGetRepositoryPath=false; } if(!strSaveAsName.equals()){ File saveFile=new File(strSaveAsName); nFileItem1.write(saveFile); //this is where i save my files . } else{ System.out.println(); } } } } is there any problem with my codes ? i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? images files uploaded to the server ...lost . I guess whether is the reason of FileUpload1.0 ? You know ,1.0 use File f =new File(.) f.deleteOnExit() ; All the upload-temp files are registered to the JVM . Got any prob ? Will the pointer mis-point to the files i wanna save and delete them all ,when the server reboot. I am really confused by the lost images files . Will FileUpload 1.1 cause the same prob ? I am not sure what is the point (delete files),so .. any suggestion and guess is welcome ! -- Martin Cooper Thanks you any way . yours,biglaughing [free as freedom] we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
Martin Cooper wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. I used FileUpload 1.0 . I am changing to 1.1 :) That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... My code is : DiskFileUpload nDiskFileUpload = new DiskFileUpload(); nDiskFileUpload.setSizeMax(50*1024*1024); nDiskFileUpload.setSizeThreshold(60*1024); i use the java.io.tmp env ( /tmp ) to safe my temptory upload files . List nFileItems = nDiskFileUpload.parseRequest(request); Iterator nIterator1 = nFileItems.iterator(); while(nIterator1.hasNext()){ FileItem nFileItem1 = (FileItem)nIterator1.next(); if(!nFileItem1.isFormField()){ String strFieldName=nFileItem1.getFieldName(); if(!strFieldName.equals(UploadTemp)){ String strFileName=nFileItem1.getName(); String strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName); if(blnGetRepositoryPath){ nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath()); blnGetRepositoryPath=false; } if(!strSaveAsName.equals()){ File saveFile=new File(strSaveAsName); nFileItem1.write(saveFile); //this is where i save my files . } else{ System.out.println(); } } } } is there any problem with my codes ? i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? images files uploaded to the server ...lost . I guess whether is the reason of FileUpload1.0 ? You know ,1.0 use File f =new File(.) f.deleteOnExit() ; All the upload-temp files are registered to the JVM . Got any prob ? Will the pointer mis-point to the files i wanna save and delete them all ,when the server reboot. I am really confused by the lost images files . Will FileUpload 1.1 cause the same prob ? I am not sure what is the point (delete files),so .. any suggestion and guess is welcome ! -- Martin Cooper Thanks you any way . yours,biglaughing [free as freedom] we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. I used FileUpload 1.0 . I am changing to 1.1 :) That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... My code is : DiskFileUpload nDiskFileUpload = new DiskFileUpload(); nDiskFileUpload.setSizeMax(50*1024*1024); nDiskFileUpload.setSizeThreshold(60*1024); i use the java.io.tmp env ( /tmp ) to safe my temptory upload files . List nFileItems = nDiskFileUpload.parseRequest(request); Iterator nIterator1 = nFileItems.iterator(); while(nIterator1.hasNext()){ FileItem nFileItem1 = (FileItem)nIterator1.next(); if(!nFileItem1.isFormField()){ String strFieldName=nFileItem1.getFieldName(); if(!strFieldName.equals(UploadTemp)){ String strFileName=nFileItem1.getName(); String strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName); Is this method call guaranteed to return a unique name, even if the same parameters are passed more than once? If not, then you could be overwriting files that were previously uploaded. Also, does this method return a full path to where the file should be saved? You are using the returned value with no additional directory specified when you call FileItem.write() later in your code, so unless this method returns the full path, write() will use whatever the current working directory happens to be. if(blnGetRepositoryPath){ nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath ()); This is too late. The repository path is part of the file item factory, and the path for a file item is set at creation time. Calling setRepositoryPath() here will do nothing at all, since the file items are all created by the time parseRequest() completes. blnGetRepositoryPath=false; } if(!strSaveAsName.equals()){ File saveFile=new File(strSaveAsName); nFileItem1.write(saveFile); //this is where i save my files . } else{ System.out.println(); } } } } is there any problem with my codes ? i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? images files uploaded to the server ...lost . I guess whether is the reason of FileUpload1.0 ? But that has nothing to so with whether deletion is secure or not, does it? It relates only to whether deletion happens at all. You know ,1.0 use File f =new File(.) f.deleteOnExit() ; All the upload-temp files are registered to the JVM . Got any prob ? Yes, there are problems with that. That is why the deletion code was changed for FileUpload 1.1. -- Martin Cooper Will the pointer mis-point to the files i wanna save and delete them all ,when the server reboot. I am really confused by the lost images files . Will FileUpload 1.1 cause the same prob ? I am not sure what is the point (delete files),so .. any suggestion and guess is welcome ! -- Martin Cooper Thanks you any way . yours,biglaughing [free as freedom] we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [fileupload] hi,all,got a delete prob
Martin Cooper wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: Martin Cooper wrote: On 6/7/06, biglaughing [EMAIL PROTECTED] wrote: hi,all i got a problem . our requirements is upload some jpg/gif to the server(images server). also,we maybe upload a file more than one time. we found , some times, all(radom) files of the folder (upload use in the server) are lost !! our version is 1.0 . The first thing you should do is upgrade to FileUpload 1.1. There were several changes in that release to the way in which uploaded files are cleaned up. I used FileUpload 1.0 . I am changing to 1.1 :) That said, without seeing any code, or reading any explanation of how you are using FileUpload, it's a little hard to know what you're doing wrong... My code is : DiskFileUpload nDiskFileUpload = new DiskFileUpload(); nDiskFileUpload.setSizeMax(50*1024*1024); nDiskFileUpload.setSizeThreshold(60*1024); i use the java.io.tmp env ( /tmp ) to safe my temptory upload files . List nFileItems = nDiskFileUpload.parseRequest(request); Iterator nIterator1 = nFileItems.iterator(); while(nIterator1.hasNext()){ FileItem nFileItem1 = (FileItem)nIterator1.next(); if(!nFileItem1.isFormField()){ String strFieldName=nFileItem1.getFieldName(); if(!strFieldName.equals(UploadTemp)){ String strFileName=nFileItem1.getName(); String strSaveAsName=nUploadImageFile.getSaveAsName(strFieldName,strFileName); Is this method call guaranteed to return a unique name, even if the same parameters are passed more than once? If not, then you could be overwriting files that were previously uploaded. Also, does this method return a full path to where the file should be saved? You are using the returned value with no additional directory specified when you call FileItem.write() later in your code, so unless this method returns the full path, write() will use whatever the current working directory happens to be. The return value is the absolute path . And our system save it to the absolute path file. if(blnGetRepositoryPath){ nDiskFileUpload.setRepositoryPath(nUploadImageFile.getTempPath ()); This is too late. The repository path is part of the file item factory, and the path for a file item is set at creation time. Calling setRepositoryPath() here will do nothing at all, since the file items are all created by the time parseRequest() completes. This code does suck. I've find this .Thanks. blnGetRepositoryPath=false; } if(!strSaveAsName.equals()){ File saveFile=new File(strSaveAsName); nFileItem1.write(saveFile); //this is where i save my files . } else{ System.out.println(); } } } } is there any problem with my codes ? i do not know whether it is the problem of fileupload component. I find this http://issues.apache.org/jira/browse/FILEUPLOAD-85 That has to do with the exact manner in which files are deleted, not whether or not they are deleted. any secure way to delete the tempotery files? so does any one has solutions ? I thought your problem was that files are being deleted that you do not want deleted, right? What does that have to do with secure deletion? images files uploaded to the server ...lost . I guess whether is the reason of FileUpload1.0 ? But that has nothing to so with whether deletion is secure or not, does it? It relates only to whether deletion happens at all. You know ,1.0 use File f =new File(.) f.deleteOnExit() ; All the upload-temp files are registered to the JVM . Got any prob ? Yes, there are problems with that. That is why the deletion code was changed for FileUpload 1.1. I will update to 1.1 ASAP. Thank you very much . btw, any toturial about the PhantomReference ? I do not know whether the 1.1 will cause the same prob I am confused by the images lost . -- Martin Cooper Will the pointer mis-point to the files i wanna save and delete them all ,when the server reboot. I am really confused by the lost images files . Will FileUpload 1.1 cause the same prob ? I am not sure what is the point (delete files),so .. any suggestion and guess is welcome ! -- Martin Cooper Thanks you any way . yours,biglaughing [free as freedom] we are confuesed by the radom delete of the jpg/gif files. any suggestion is welcome. thank you all ! yours,biglaughing [free as freedom] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL