You all right about ESXi issue, df -k shows only the virtual machines storage and that error is occured because of the max number of files allowed by OS.
I will try out the things Andre, Pid and Chris suggested and then i'll hopefully write you good news about my problem. Again thanks for all your help. I'll be posting soon about the results. Best, On Fri, Jul 2, 2010 at 5:27 PM, André Warnier <a...@ice-sa.com> wrote: > Murat Birben wrote: > >> Actually i'm not familiar with the interanls of >> enctype="multipart/form-data" thing. I think, i should read about this >> right? >> > Right. > > Start here : > http://www.w3.org/TR/html401/interact/forms.html > 17.13 Form submission > > Then graduate to this if you really want to know the details : > RFC 2045 > http://www.ietf.org/rfc/rfc2045.txt > > But, as a summary : > With the form you showed earlier, what the browser will send to the server > is a block of text data looking (approximately) like this : > > (start) > POST /ResourceUploadServlet HTTP/1.1 > Content-type: multipart/form-data; boundary=-----something---- > .. more header lines, followed by one empty line .. > > -----something---- > Content-type: text/plain > Content-disposition: form-data; name=FileName > Content-length: 18 > > some-file-name.pdf > -----something---- > Content-type: text/plain > Content-disposition: form-data; name=Path > Content-length: 10 > > /some/path > -----something---- > Content-type: application/pdf > Content-disposition: form-data; name=Content; > filename=some/path/and/file-name.pdf > Content-length: 132456 > Content-transfer-encoding: Base64 > > > pcEAJ2AJBAAA+BK/AAAAAAAAEAAAAAAABgAAHAgAAA4AYmpiauvI68gAAAAAAAAAAAAAAAAAAAAA > > AAAHBBYALhAAAImiAACJogAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA > > AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAMADAAAAAAAAwAMAAMAD > > AAAAAAAAwAMAAAAAAADAAwAAAAAAAMADAAAAAAAAwAMAABQAAAAAAAAAAAAAANQDAAAAAAAA3AYA > > AAAAAADcBgAAAAAAANwGAAAAAAAA3AYAAAwAAADoBgAADAAAANQDAAAAAAAArAwAAP4AAAAABwAA > > AAAAAAAHAAAAAAAAAAcAAAAAAAAABwAAAAAAAAAHAAAAAAAA2wcAAAAAAADbBwAAAAAAANsHAAAA > > AAAAKwwAAAIAAAAtDAAAAAAAAC0MAAAAAAAALQwAAAAAAAAtDAAAAAAAAC0MAAAAAAAALQwAACQA > > AACqDQAAaAIAABIQAAByAAAAUQwAABUAAAAAAAAAAAAAAAAAAAAAAAAAwAMAAAAAAADbBwAAAAAA > > AAAAAAAAAAAAAAAAAAAAAADbBwAAAAAAANsHAAAAAAAA2wcAAAAAAADbBwAAAAAAAFEMAAAAAAAA > > AAAAAAAAAADAAwAAAAAAAMADAAAAAAAAAAcAAAAAAAAAAAAAAAAAAAAHAADbAAAAZgwAABYAAAD3 > .. and many similar lines > ... > (end) > > Each <input> of the <form> is going to result in one of the "form-data" > blocks above. The <input type="file"> will result in some very large block > like the last one, which contains the binary data of the file, encoded in > Base64 encoding. > > Tomcat 5.5 (and 6.0), natively, do not contain any standard code capable of > parsing such a POST data format and returning it nicely to your servlet. > (And you cannot just do a request.getParameter('Content') either.) > (but with Tomcat 7.0 however you should be able to). > > To handle this kind of POST with Tomcat 5.5 or 6.0, you have either to do > the work yourself (not recommended), or use something like FileUpload to do > it. > But you cannot just read the body of the request, and copy it to a disk > file. > Or rather, you can, but then you will have the whole block above in your > disk file. > > I do not remember how the FileUpload module really works, but it allows you > to retrieve each of the blocks above (=form parameters) independently, and > it will do all the decoding for you. > For the file part (named "Content"), it probably gives you already a > Stream, from which you can read to retrieve the (decoded) content of the > file. > THAT is what you should be copying to a disk file. > > Got the general idea ? > > And, as pid was saying, the FileUpload documentation should certainly > provide some good examples. > > But, no matter how you do this, > > <read this 3 times> > /NEVER/ accept the path or the filename that the user is entering in the > form, to just write this file to disk. > </read this 3 times> > > Remember what the user has entered, and write it somewhere as a text. But > create a path and a (unique) filename yourself, in your servlet, to write > the file. > That will protect you not only against nasty people trying to crash your > server, but also against innocent users entering file names with spaces in > them, or funny characters that are illegal in a filename on your system, or > re-using a filename that already exists. > (to name just a few of the things that can happen). > > All that still does not tell us why your servlet creates 0-size files, but > maybe with the above explanation you can figure this out yourself. > > My scenario : > - your first getParameter() call "sucks in" the whole POST (all the above) > - your next getParameter() calls do not have anything else to get, and > return null > - by the time you try to read the body of the POST, there is nothing left, > so you also get null > - and then you write this (null) to the output file, and you get a > null-size file. > > Repeat the above cycle once for each POST. > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Murat BIRBEN
