Edit report at https://bugs.php.net/bug.php?id=63618&edit=1
ID: 63618 User updated by: roman dot hlynovskiy at gmail dot com Reported by: roman dot hlynovskiy at gmail dot com Summary: filesize returns negative values for big files -Status: Duplicate +Status: Closed Type: Bug Package: Filesystem function related Operating System: linux PHP Version: 5.3.19 Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2012-11-29 10:45:34] [email protected] 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. ------------------------------------------------------------------------ [2012-11-29 10:41:47] [email protected] 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] [email protected] 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 ------------------------------------------------------------------------ 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
