Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^2: File Upload On Windows 8 and Perl

by skosterow (Novice)
on Jul 04, 2015 at 16:20 UTC ( [id://1133168]=note: print w/replies, xml ) Need Help??


in reply to Re: File Upload On Windows 8 and Perl
in thread File Upload On Windows 8 and Perl

okay this is wired! I GET THE SAME result with that script you showed me - ummm this HAS to be something my servers doing?? any suggestions??

  • Comment on Re^2: File Upload On Windows 8 and Perl

Replies are listed 'Best First'.
Re^3: File Upload On Windows 8 and Perl
by marinersk (Priest) on Jul 04, 2015 at 16:40 UTC

    I suspect you will have found it upon re-reading the thread, but just in case, see my reply above at Re^5: File Upload On Windows 8 and Perl.

    Further note, you seem to be mixing slashes and backslashes in your filename -- I'm a stickler for consistency, admittedly often beyond what is needed, but experience has taught me that computers and inconsistency mix badly at times.

    Finally, if adjusting the filename string the way you think you should doesn't fix the issue, you might consider having the script display its values to the browser before initiating the actual upload, just to make sure there isn't something else amiss. Input filename, output filename -- anything that could matter. Do not fall again for the trap of presuming to know what does matter. When stuff is broken, it pays to be extremely circumspect.

    print "Content-Type: text/html\n\n"; print "<!DOCTYPE html>\n"; print "<html>\n"; print " <head>\n"; print " <title>My CGI File Upload Test</title>\n"; print " </head>\n"; print " <body>\n"; print " <p>\n"; print "\$upload_dir = [$upload_dir]<br />\n"; print "\$filename = [$filename]<br />\n"; print "\$upload_dir/\$filename = [$upload_dir\/$filename]<br />\n" +; print " </p>\n";

    Another tidbit I ran into from my own experiences -- if the server is a Windows server, sometimes they don't set permissions on TEMPthe way you'd expect, and the CGI uploader temporarily writes there. Total upload failure if you don't have write permissions to the TEMPdirectory. A workaround is to establish a different directory for it to work with as its workspace:

    # Needed to avoid dependence on C:\TEMP being world read+write BEGIN { $TempFile::TMPDIRECTORY = './'; }

    It's been my experience that using './'for $TempFile::TMPDIRECTORYtends to result in the cgi-binor similar directory being used -- but it depends on where your Perl CGI script lives -- in your case, I seem to recall your form invokes it from /test/, so make sure your script has write permission there, or change the value used for $TempFile::TMPDIRECTORY.

      This is the response I get from the snip you posted:
      $upload_dir = [images-user] $filename = [20150608_144833.jpg] $upload_dir/$filename = [images-user/20150608_144833.jpg]
      it looks right! Again like i said I can see the file being created in the directory. I have two monitors and i have the DIR open on one and i hit submit in the other. the script goes through its thing - returns the correct page, the file is created but its like there no data IN the file. grrrr :)

        Okay, there's some basic checking on your part that needs to be done -- I'll get to that in a moment.

        At this point I would definitely examine the most excellent suggestion raised by RichardK in Re^5: File Upload On Windows 8 and Perl. Hard evidence is always better than guesses, so take anything you can get in that space. Software engineering is, after all, a blend of art and science.

        Things you'll need to poke around and check -- confirm that images-user is not at the root (i.e., should it be /images-useror \images-userlike you coded it), or should it be a subdirectory of your CGI directory as the browser debugging has shown it to be, etc. -- only you can check those, and you need to try to catch yourself at your own assumptions.

        An example of such an error: What if the file you are seeing was placed there by an early test which failed for a completely different reason, but you never deleted it, and now you are not writing to the same location? It would be completely easy and understandable to make the mistake -- and it would be exactly that -- of assuming that just because the file is in the right place, that your current script is trying to write it there.

        Second-guessing yourself is part science, part art, to be sure; but it is an absolutely critical skill to develop in this profession. You know this, I suspect -- just highlighting that a common trap is to make an assumption and move right past critical analysis. You're not allowed to ask how I know this.  :-)

        Finally, also consider if necessary the use of the TEMPdirectory override I noted above.

        I know it feels like you're circling the problem and not getting at it -- but if you systematically eliminate all the possibilities, and pay attention to what you see whilst you're hunting, odds are you'll find it eventually. Patience, Persistence, Attention to Detail -- all key tools in the troubleshooter's toolbox.

        I would be interested to know when you resolve this; and always, toss out more questions if they come up.

Log In?
Username:
Password:

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

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

    No recent polls found