Edit report at https://bugs.php.net/bug.php?id=63618&edit=1
ID: 63618
Updated by: pajoye@php.net
Reported by: roman dot hlynovskiy at gmail dot com
Summary: filesize returns negative values for big files
Status: Duplicate
Type: Bug
Package: Filesystem function related
Operating System: linux
PHP Version: 5.3.19
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2012-11-29 10:41:47] pajoye@php.net
Fix summary
------------------------------------------------------------------------
[2012-11-29 10:36:22] roman dot hlynovskiy at gmail dot com
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.
------------------------------------------------------------------------
[2012-11-27 10:59:53] johannes@php.net
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.
------------------------------------------------------------------------
[2012-11-27 07:11:39] roman dot hlynovskiy at gmail dot com
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
------------------------------------------------------------------------
[2012-11-27 06:40:45] pajoye@php.net
LFS is not supported by default. See other feature requests about this issue.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63618
--
Edit this bug report at https://bugs.php.net/bug.php?id=63618&edit=1