4.2.0-dev File Upload yields only "Trailers"

[meta] PHP-General post a week ago got me one flame and no useful content in my Inbox... Since bugs.php.net won't let me put in 4.2.0-dev, I'm posting here next... Mebbe I need to start posting again. :-^ If nothing comes of this post, is php-dev the next stop, or should I just give up? I may be providing a bit too much information here, but that's better than "It's broken", right?... [/meta] I'm consistently seeing file uploads get only the trailing N bytes of the file if the file is over a certain size. This is on applications that worked flawlessly under previous versions on the "old" ISP, but I had to start using http://php.net/move_uploaded_file and working around/through safe mode on the new ISP so maybe I'm just using or abusing those in a bad way... The limit does *NOT* seem to be a constant, but perhaps the ISP's attempt to alter the File Upload Limit has affected this over time, and I'm just not correctly anticipating an over-limit file upload... I think the ISP's limit is like 20 Meg or something ridiculously high though, and even my nifty cable-modem doesn't make testing *that* pleasant. Yes, I can and will limit it lower in the HTML and .htaccess before this goes live, but I'm trying to not add yet another variable at this point. If you've got a T1 all to yourself and want to try it, go for it, without getting silly, please. I guess I'm seeking reassurance that: A) File upload is not known to be broken in 4.2.0-dev B) move_uploaded_file completely finishes and CLOSES a file before returning, right?... C) The behaviour when the upload limit is exceeded would be something more useful than move_uploaded_file() returning true and giving me only the last N bytes that were within the limit... Or am I supposed to compare the highly-suspect $_POST_FILES[foo][size] variable provided by the browser to what I actually received?... Perhaps my problem boils down to "What *SHOULD* one do to handle the file-upload limit in a 'pretty' way?" If so, Sorry. The variance in the amount of data successfully acquired "feels" like move_uploaded_file is leaving the file open, and then I fopen() it, and get the latter half of the file due to file-pointer cross-wiring or something. It's entirely possible I'm just being stupid, though... That happens a lot until I pound new ideas through this thick skull of mine. Here is the top bit of phpinfo(): PHP Version 4.2.0-dev System OpenBSD o2 2.9 conf#0 i386 Build Date Jan 29 2002 15:56:06 Configure Command './configure' '--with-apache=../apache_1.3.22' '--with-config-file-path=/var/www/conf' '--enable-trans-sid' '--enable-ftp' '--enable-sockets' '--with-openssl' '--with-gd' '--with-jpeg-dir=/usr/local/lib' '--with-png-dir=/usr/local/lib' '--with-tiff-dir=/usr/local/lib' '--with-zlib-dir=/usr/include' '--with-mysql' '--with-pdflib' '--with-mcrypt' '--with-pgsql=/usr/local' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /var/www/conf/php.ini ZEND_DEBUG disabled Thread Safety disabled This program makes use of the Zend Scripting Language Engine: Zend Engine v1.2.0, Copyright (c) 1998-2002 Zend Technologies Upload Script: http://nogenre.com/aandr/aandr.phps Cron job referred to in comments in upload script: http://nogenre.com/aandr/approve.phps php.ini http://nogenre.com/aandr/php-ini.phps Full phpinfo(): http://nogenre.com/phpinfo.php Try it in action -- Upload a nice big MP3 of your favorite indie band's music here: http://nogenre.com/aandr/aandr.htm [Hey, it might even get them a good record deal from a mid-sized label. There are no good record deals from a major label.] If it's not really an MP3, it should be rejected, so I'm afraid you really with need an MP3, not just an "MP3-sized" file. Or, at least, that's what my code is *supposed* to do... If you have no MP3's available, might I suggest any of the ones from this radio station: http://nogenre.com/count_to_3.m3u :-) Any other information provided upon request. -- Got Music? http://l-i-e.com/artists.htm