Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 56780
Status: resolved
Priority: 0/
Queue: CGI

People
Owner: Nobody in particular
Requestors: j [...] imperial.cc
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Windows 7 and CGI.PM undefined upload handle
Date: Wed, 21 Apr 2010 20:01:12 +0800
To: <bug-CGI.pm [...] rt.cpan.org>
From: "Jason Rose" <j [...] imperial.cc>
Hi, It appears that CGI.PM has a platform specific issue with Windows 7, possibly only 64-bit version, in that it always gives undefined handle when doing a $query->upload{field_name'}. Observations: . My code works fine on Windows XP 32bit running all Apache and ActivePerl 5.8/5.10 versions laptop dev environment . My code works fine on Linux Apache build running on B luehost.com hosted solution . Key point: the code works, but has issues on Windows 7 64-bit unless you downgrade to ~v3.25 (I discovered this when rebuilding my dev environment) Potentially useful information (from local dev Win7-64 evironment using 3.48 and 3.49 CGI.PM) . Tried multiple versions of Apache 2.x - no versions worked. . Tried multiple versions of 5.8/5.10 ActiveState PERL (both 32-bit and 64-bit versions) - no versions worked . $ENV{CONTENT_LENGTH} always returns the correct number, so the multipart/form-data and content upload is ok. . When uploading a 1Gb file, I do see the CGIxxxx temp file in C:\Windows\temp increasing in size. so it's not permissions issue with Windows 7 . The problem seems to be that the CGIxxx temp file is deleted instantly before an upload handle is generated . In some versions of CGI.PM (I can't tell you the exact one, but between 3.29 and 3.39 the CGIxxx temp file is written into the local script folder instead of a temp folder. The problem there is two-fold: it still doesn't return an upload handle and it doesn't delete the temp file either! CODE $filename = $q->param('Hfile'); $type = $q->uploadInfo($filename)->{'Content-Type'}; $tmpfilename = $q->tmpFileName($filename); $filesize=-s $tmpfilename; $ZLOG.="Received file '$in{Hfile}' according to \$ENV{CONTENT_LENGTH} is size $ENV{'CONTENT_LENGTH'}<BR>"; $ZLOG.="Running CGI.PM $CGI::VERSION<BR>"; $ZLOG.="Temporary file name is '$tmpfilename' and the type is '$type' with size of '$filesize'. <BR>"; $lightweight_fh = $q->upload('Hfile'); $ZLOG.="The handle is '$lightweight_fh'<BR>"; FAILED OUTPUT ON WIN7-64 DEV PLATFORM Received file ' httpd.conf ' according to $ENV{CONTENT_LENGTH} is size 19324 Running CGI.PM 3.49 Temporary file name is 'C:\Windows\TEMP\CGItemp63983' and the type is 'text/plain' with size of ''. The handle is '' SUCCESSFUL OUTPUT ON LINUX BLUEHOST AND WINXP PLATFORM Received file 'httpd.conf' according to $ENV{CONTENT_LENGTH} is size 19324 Running CGI.PM 3.49 Temporary file name is '/usr/tmp/CGItemp30111' and the type is 'text/plain' with size of '18847'. The handle is 'httpd.conf' 534 bytes loaded. Relevant external post http://forums.devshed.com/perl-programming-6/cgi-upload-problem-on-windows-c omputer-cgi-pm-related-669763.html#post2451887
Subject: Re: [rt.cpan.org #56780] Windows 7 and CGI.PM undefined upload handle
Date: Wed, 21 Apr 2010 09:14:32 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Thanks for the detailed reports, Jason. I'm not aware that any of the current CGI.pm contributors are Windows 7 users, but a patch is welcome, and you could also ask for help in general forum like perlmonks.org. Mark
This issue has been copied to: https://github.com/leejo/CGI.pm/issues/73 please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.
I've refactored all the temporary file handling logic to use File::Temp so this issue should no longer be present. Dev version is available for testing, 4.04_02, so if you can have a look and confirm/deny then that would be useful. Either way, i'm closing this as it's not something i have the resources or time to look at, so i'm going to cop out and say "patches (with tests) welcome" if the problem persists.