php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57728 No temporary file written
Submitted: 2007-07-02 12:22 UTC Modified: 2009-01-21 05:58 UTC
Votes:2
Avg. Score:4.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: the-pulse at gmx dot net Assigned:
Status: No Feedback Package: uploadprogress (PECL)
PHP Version: 5.2.1 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: the-pulse at gmx dot net
New email:
PHP Version: OS:

 

 [2007-07-02 12:22 UTC] the-pulse at gmx dot net
Description:
------------
I am using php 5.2.0-8+etch4 on Ubuntu (feisty). I've installed uploadprogress-0.3.0-beta via pecl.
The function uploadprogress_get_info is available, but always returns null. This is obviously the case because no temporary file is written into the /tmp directory. The UPLOAD_IDERTIFIER is the first input element in the form, and its value is a 32-digit hex number.
I've tried to set a filename template:
uploadprogress.file.filename_template=/tmp/phpupload-%s.tmp
- but that had no effect.

Thanks for any help

Sven


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-07-02 15:06 UTC] the-pulse at gmx dot net
Correction: It's debian etch, not Ubuntu.
 [2007-08-23 22:42 UTC] ramsey@php.net
Can you replicate this issue and provide the code you're using?

I can't duplicate your problem. Here's my code:

file-upload.php (I use uniqid() to generate the UPLOAD_IDENTIFIER):
<form action="file-upload.php" method="post" enctype="multipart/form-data">
<input type="text" name="UPLOAD_IDENTIFIER" value="46ce4381a64ee" />
<input type="file" name="upload_file" />
<input type="submit" value="Send" />
</form>

I pick a rather large file and set it to upload, then I open a new browser window/tab and browse to upload-progress.php?id=46ce4381a64ee

Code for upload-progress.php:
<?php
var_dump(uploadprogress_get_info($_GET['id']));
?>

Seems to work for me, and when I check /tmp, the file is there during the upload process.
 [2007-11-07 16:55 UTC] chrysb at gmail dot com
I am having the same problem that it is not writing a temp file.

uploadprogress shows up in phpinf(); and I have PHP 5.2.4

My /tmp directory is 777 and here is my code, I made a simple simple form to test it:

<form method="post" enctype="multipart/form-data">
	
	<input type="hidden" name="UPLOAD_IDENTIFIER" value="<?=uniqid()?>">
	
	<input type="file" name="file">
	
	<input type="submit">
</form>
 [2007-12-29 16:45 UTC] jon dot nalley at gmail dot com
Some folks may be having issues if the upload_max_filesize ini variable is smaller than the file they are attempting to upload.  I found that if the file I was attempting to upload was larger than the allowed size, uploadprogress_get_info() would always return null.
 [2008-03-25 13:35 UTC] etzool at hotmail dot com
With 5.2.5 and 5.2.6RC1 on Gentoo, I get null from uploadprogress' info method as well, presumably because the temp file is not being written during the upload (I have verified that it is not being written).

Under CentOS 4 running PHP 5.2.4 (the old server), this works without issue.  I cannot downgrade to this version within the portage tree, so I may just manually install 5.2.4 and see if this solves the problem.
 [2008-07-21 10:23 UTC] nick at carbidefinger dot net
I can also confirm that this happens on CentOS 4 with PHP 5.2.5 under suphp

however not in all instances, rarely but on some occasions the temporary files are created but remain empty and uploadprogress_get_info() returns NULL each time
 [2008-11-05 23:20 UTC] uploadprogress at gzmarketing dot com
I'm on Ubuntu Feisty and was having this same problem (no temp file being written), and it turned out to be caused by the Suhosin hardening patch.  Upgrading the Suhosin extension to the latest version fixed the problem.  It took 3 hours to track down!
 [2009-01-21 05:58 UTC] chregu@php.net
the  Suhosin extension problem is solved. I didn't get more 
info to actually track down the problem
 [2011-08-29 19:53 UTC] syo-0942 at ryucom dot ne dot jp
http://www.searchmedsonline.com/ buy valtrex online prescription =-[[ http://www.medsbalance.net/ nexium >:-DD
 [2011-08-31 20:33 UTC] ryutu-45 at crux dot ocn dot ne dot jp
http://www.unamed.net/ propecia 81248 http://www.availablemeds.com/ colchicine ebak
 [2011-09-01 21:15 UTC] mediguide at abortion-help dot com
http://www.pillscity.net/ valtrex 4747 http://www.pillschance.com/ zovirax azlj
 [2011-09-03 21:05 UTC] 428 at okidenko dot co dot jp
http://www.medmuster.com/ priligy 1634 http://www.onlinemedspro.com/ cymbalta 8-OO
 [2011-09-12 20:52 UTC] info at kanehide-bio dot co dot jp
http://www.medicsupport.net/ prednisone stnl http://www.topratedpills.net/ topamax and excessive weight loss pok
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Nov 18 23:01:35 2019 UTC