Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

CGI File upload, resulting files 0 bytes long

by Mandor (Pilgrim)
on Mar 07, 2001 at 01:33 UTC ( [id://62588]=perlquestion: print w/replies, xml ) Need Help??

Mandor has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I am using this code :
open ( UPLOAD, ">$file" ); while ( read ( $data, $buffer , 1024 ) ) { $buffer =~ s/\r//g; print UPLOAD $buffer; } close ( UPLOAD );
For receiving a file I get from a form and am testing it on Xitami ( Win32 ). But the file resulting is just 0 bytes long. I gladly appreciate any help as I really don't have a clue why this is happening. Thank you.

Replies are listed 'Best First'.
Re: CGI File upload, resulting files 0 bytes long
by Corion (Patriarch) on Mar 07, 2001 at 01:47 UTC

    Two things - One, always use binmode() when opening files for reading or writing. This dosen't hurt under Unix, and it's certainly necessary under Windows.

    The second, and even more important thing, use CGI; ! CGI.pm will make uploading files to your server as easy as :

    # Copy a binary file to somewhere safe open (OUTFILE,">>/usr/local/web/users/feedback"); binmode OUTFILE; while ($bytesread=read($filename,$buffer,1024)) { print OUTFILE $buffer; }
    also including an enforcement of a maximum upload size and many nifty other things. CGI.pm is your friend !

      And while we're giving general advice, always check to see if your file gets opened in the first place!

      open (OUTFILE,">$file") or die "Couldn't open '$file': $!\n";
      Lincoln Stein describes binmode() in his most meritorious work Network Programming With Perl. He writes:
      In text mode, however, the standard I/O library automatically translates LF into CRLF pairs on the way out, and CRLF pairs into LF on the way in. The virtue of this is that it makes text operations on Windows and UNIX Perls look the same—from the programmer's point of view, the DOS text files end in a single \n character, just as they do in UNIX. The problem one runs into is when reading and writing binary files—such as images or indexed databases—and the files become mysteriously corrupted on input or output. This is due to the default line-end translation. Should this happen to you, you should turn off character translation by calling binmode() on the filehandle.
      Generally one ought not to run binmode() when one is reading and writing text on Windows and VMS system. But reading between the lines of Stein's advice makes me think that perhaps one ought to turn on binmode only as needed even when running binary files.

      When I used to open up DOS binary files in text editors I would often see what looked like meaningful text there. Perhaps "to every thing there is a season" as it says in Ecclesiastes and even binary files should sometimes be run without binmode() in order to handle these meaningful snippets of text in binary files.

        Yes, I get the same "between the lines" impression, but that doesn't change the fact that such advice is just wrong.

        Always use binmode() when dealing with binary data in files and never use bindmode() when dealing with only text data in files.

        If you read a binary file without binmode() in DOS and expect to find the text bits in better shape, then you will be surprised when the binary data contains CTRL-Z and your program refuses to read past that, no matter how much text appears later in the file.

        I find particularly unfortunate the "Should this happen to you" bit. "Well, I know it is possible that dealing with binary files w/o binmode() might cause problems but you should really wait to fix such problems until such time as you stumble upon them."

        I'm disappointed at how frequently discussions of binmode() say stuff like "Use this if you aren't on Unix and...".

                - tye (but my friends call me "Tye")
      Hi, thanks for your help.
      I have just tried it that way and still isn't working. I tried printing out $bytesread but it seems to have no value.
      I also checked if the filename that gets passed to my code is correct and that's the case. Am I missing something?
Re: CGI File upload, resulting files 0 bytes long
by AgentM (Curate) on Mar 07, 2001 at 01:59 UTC
Re: CGI File upload, resulting files 0 bytes long
by fpi (Monk) on Mar 07, 2001 at 14:44 UTC
    1. Make sure you are sending the ENCTYPE as "multipart/form-data" in your form
    2. Make sure you are using CGI.pm to receive it.
    3. It's not unreasonable to check if it works differently with IE vs. Netscape, and what version you are using. The cgi.pm docs say that inconsistencies arise with different combinations of platform/webserver/browser.

    I had the exact same problem with a MacOS9/WebSTAR system, so I looked at CGI.pm more closely. The docs say that the problem could be in the creation of the temp file, which CGI.pm creates with your upload, then transfers it to your specified destination. In my case, I was able to determine that a temp file was being created, but still only 0 bytes .But I was sure that the file was being uploaded by (transferred to) the webserver, just not saved at all. Some said the OS was unable to transfer large files, but my best guess had to do with the CGI glue from the webserver program to perl...
Re: CGI File upload, resulting files 0 bytes long
by wardk (Deacon) on Mar 07, 2001 at 02:29 UTC

    the code looks alright. but you didn't include the code that gave you the $data filehandle. be sure that $data was retrieved something like so:

    my $data = $query->param("uploadfileTagname");

    a common gotcha is opening the uploaded filehandle for read, then trying to write it back out. at least it "got" me....once :-)

      I get my $data like this my $data        = $cgi -> param ( 'data' );
      Give it to my subroutine like this &receive_upload ( $data );
      And receive the value in my subroutine like this my $data = shift;

        from perlfaq5...

        For passing filehandles to functions, the easiest way is to preface them with a star, as in func(*STDIN). See the section on Passing Filehandles in the perlfaq7 manpage for details.

        from perlfaq7...

        How can I pass/return a {Function, FileHandle, Array, Hash, Method, Regexp}?
        With the exception of regexps, you need to pass references to these objects. See the section on Pass by Reference in the perlsub manpage for this particular question, and the perlref manpage for information on references.

Re: CGI File upload, resulting files 0 bytes long
by markjugg (Curate) on Mar 07, 2001 at 07:47 UTC
    I've got a guess here, but because it sounds like a wall I've run into before: This might not be a perl problem at all. Did you set the encoding to be something like "multipart/form-data" in your HTML <FORM> tag? There's more documentation on this in the CGI.pm docs.

    -mark

      I'd put my money on this solution. If you didn't specify the correct mime-type when posting the file from the upload form, then there's nothing for the Perl script to accept.
Re: CGI File upload, resulting files 0 bytes long
by Stamp_Guy (Monk) on Mar 07, 2001 at 05:21 UTC
    Xitami? That could be your problem right there. I had a terrible with CGI on Xitami so I switched to Sambar. Try that out and see if it fixes your problem. You might also want to post the entire upload script so we can see exactly what's going on. I had this problem before, so if you need some further help on it, go ahead and email me here.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://62588]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2024-04-25 23:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found