|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #34750 filesize()/stat() fails on too big files
Submitted: 2005-10-06 10:08 UTC Modified: 2017-01-10 06:50 UTC
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
 [2005-10-06 10:08 UTC] aulbach at mayflower dot de
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


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


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

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-10-06 10:22 UTC]
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]
-Status: Open +Status: Closed -Assigned To: +Assigned To: krakjoe
 [2017-01-10 06:50 UTC]
This is no longer applicable.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sun May 16 22:01:24 2021 UTC