[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
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
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
