Edit report at https://bugs.php.net/bug.php?id=63618&edit=1
ID: 63618 Updated by: [email protected] 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] [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 ------------------------------------------------------------------------ [2012-11-27 06:40:45] [email protected] 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
