php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #34750 filesize()/stat() fails on too big files
Submitted: 2005-10-06 10:08 UTC Modified: 2017-01-10 06:50 UTC
Votes:25
Avg. Score:4.5 ± 1.0
Reproduced:22 of 22 (100.0%)
Same Version:12 (54.5%)
Same OS:11 (50.0%)
From: aulbach at mayflower dot de Assigned: krakjoe (profile)
Status: Closed Package: *General Issues
PHP Version: 5CVS,6CVS,4CVS (2008-02-22) OS: *
Private report: No CVE-ID: None
View Developer Edit
 [2005-10-06 10:08 UTC] aulbach at mayflower dot de 
Description:
------------
Writing a php command-line script, which scans all my files on my big raid, I mentioned, that PHP is not able to handle the case, when the files are bigger than 4 GB. But this is more and more used, cause for example complete DVD-images are just put in one file.

PHP itself cannot handle bigger numbers, cause it uses 32 bit integer.

Currently I help me with `ls` but that's no real solution.

Everyone is using 64 bit integer now. There are many cases, timestamps for example.

For now I suggest, that the number is stored as a string, if it gets too big. I use that number only to write it into the database (which can handle 64 bit int), so for that case this is correct.

For long term, I suggest a mechanism, that automatically assigns 64 bit integer, if the number gets too big.


Reproduce code:
---------------
$fsize = filesize($path); // returns invalid if file is too big, the rest of the program will fail, if I assume, that there will be a number

OR

$stats = stat($path); // complete record invalid

Patches

double_filesize.patch (last revision 2010-08-23 20:06 UTC by dominic dot benson at thirdlight dot com)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-06 10:22 UTC] derick@php.net 
This is not a bug, but a feature request.
 [2005-10-06 10:38 UTC] aulbach at mayflower dot de 
- it's not a feature request, it's a workarround over a problem, that otherwise cannot be solved within PHP! (without calling external programs)

- For longer term, there is no question, that PHP needs 64 bit integer.
 [2010-08-23 22:11 UTC] dominic dot benson at thirdlight dot com 
The patch takes advantage of floats being doubles in PHP (with 53 bits of precision under linux 32) - in the patch LLONG_MAX is hardcoded as its actual value, this should really be derived from limits.h. It depends on PHP being built with the largefile compile flags to actually work (it fixes the integer wrapping that then occurs). It should be harmless on 64 bit, but ideally configure would check long vs. double on the system and include the additional section or not based on that.
 [2010-08-24 10:53 UTC] aulbach at mayflower dot de
-Package: Feature/Change Request +Package: *General Issues
 [2010-08-24 10:54 UTC] aulbach at mayflower dot de 
Nice. Perhaps I mix something up, but don't forget to fix stat() too. :)
 [2012-03-11 12:16 UTC] sam_account3 at hotmail dot co dot uk 
Please avoid writing '*' in the OS field.  This is particularly important here, as your request is platform-dependant.  PHP uses 4 bytes to store an integer on 32-bit systems, and 8 bytes on 64-bit systems.
 [2012-03-12 14:25 UTC] aulbach at mayflower dot de 
Off-Topic @ sam_account3 at hotmail dot co dot uk:

How could the operating-system be important in this bug? Either PHP can handle the filesize or not. Otherwise the bug isn't fixed, because at OS1 the bug appears then after 32 Petabytes but at OS2 the bug appears only Tuesdays.

It's no matter how it's done/how the size is stored, but when it is fixed, there should be no limits such as the operating system.

For example: To go arround the limits of this bug I stored the filesize as a string, like a database does. So PHP handles the filesize not as INT but as STRING. This is a kind of fix, which will work anymore in 30 years. Perhaps some of you have smarter ideas... :)
 [2017-01-10 06:50 UTC] krakjoe@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2017-01-10 06:50 UTC] krakjoe@php.net 
This is no longer applicable.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 14:01:29 2024 UTC