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]
