LFS is not supported by default. See other feature requests about this issue.

hmm, feature is something missing in a product, however this one is a plain bug.
perl, python, 3-line c program, stat, ls they all return correct size. what is wrong with php to return correct filesize?
this is strace cut:
---
stat64("/home/data/bigfile.data", {st_mode=S_IFREG|0644, st_size=2336962885, ...}) = 0
write(1, "-1958004411\n", 12-1958004411
---
it's clear that from system level correct size is returned. it's a matter of using correct types to store and return the value from php perspective

PHP's internal integer type is a signed `long`. with 32bit 2336962885 is out of range. While properly printing it gives you the correct value: 

php -r 'printf("%u", -1958004411);'
2336962885

Besides that there are projects for large file support (while that's not as relevant on most 64bit systems [except windows 64bit] these days where it works out of the box) and for aritrary size "integer" types. But both projects aren't trivial due to the wayand amount of 3rd party libraries PHP interacts with. If you have a constructive proposal/solution for those we're more than happy to implement those, though.

Yep, I have a constructive proposal. I have 10y+ experience working for 1000+ company, so according to my experience a project created to solve a particular problem will either become never-ending story or will be realized by the time no one needs it.

I agree - there are thousands of module ecosystem around php, but all those testing efforts should be made by the module-developers and their user ecosystem, not the core php team. I am not quite familiar with php development approach, but for example linux way looks rather effective. stable stuff goes to even-numbered releases, test stuff goes to odd-numbered releases. 

I am pretty sure this is not the only bug waiting for 'big project to bang' and fix it. So my proposal would be to collect all those bugs, fix all of them in one shot and provide non-stable -bugshot release for those who will be willing to test it within their app ecosystem.

Also try to understand the situation from user-perspective. If there is a bug, which has several pages of workarounds published on the official page and most probably it has been in place for ages, it looks like something is wrong with bug-fix approach in php. If this is so - how can I trust a product, which might have a critical bug affecting overall system performance (for example) for my product and which could have never been fixed. I would never feel comfortable in this situation.

Fix summary

Excuse me but where is your proposal?

What does release cycles or management (Btw, we do have a release management 
process since 5.4.0) have to do with LFS support?

And what do you propose? Should we (php developers) go out and fix the hundred 
of external projects used by PHP and PHP extensions?

What is your analysis on this problem besides 'it does not work'?

What do you suggest for 64bit integer or size_t to be exposed on all supported 
platforms? Using double? Add a new type?

So please, before you go down the word and blame us for being bad at our jobs 
(amazingly enough, 77% of the website world wild use php, so we may be not so 
bad), do your homework and learn the how&why about your feature request.

Thanks for your understanding and feedback.

My proposal was clear an straightforward - fix the problem and let other module developers think of compatibility. And I don't see a reason why should I (as an end user) make an 'analysis of problem' or suggest which data types should be used - this is dev job to find a solution. 
Whenever I leave my car at dealer's maintenance I don't expect dealer to tell me his story of making it so hard to fix my car and I don't see much difference for this case.
Nevertheless I got your point and really wish you guys go from 'tech-centric' to 'customer-centric' approach otherwise all those 77% (which are decreasing by the way last years) will suddenly drop below 30.

Nobody said this feature won't be implemented at some point.

However, you are not a customer but a user. Most of us do this for free and during 
their free time. Contributions are welcome, we have RFCs to get new features in, 
etc. Feel free to step in.

ps: re set duplicate status as we have other report for this request