Bug #74395 [Opn]: Support 4g files in stream_copy_to_stream() on 32 bit php builds

Edit report at https://bugs.php.net/bug.php?id=74395&edit=1 ID: 74395 Updated by: ab@php.net Reported by: maggus dot staab at googlemail dot com Summary: Support 4g files in stream_copy_to_stream() on 32 bit php builds Status: Open Type: Bug Package: Streams related PHP Version: 7.1.3 Block user comment: N Private report: N New Comment: 32-bit PHP is strict and the key is simplicity and performance. To have 64-bit integers always is much bigger topic than just changing the datatype. That would mean a significant performance impact, and aslo things like date, file stat, PHP streams, external libs and many portability cases would require a deep refactoring in PHP. For stat - well, that's an issue, for date it's still ok. The suggested string conversions in the case look not justified. LFS is not something required every day, so performance is more relevant. In some cases it is solvable with a completely sane approach like listed in the first comment, some workarounds for stat are also possible, even not nice. I would tend to set this to won't fix therefore, as it sohuld be either some proper core solution, or 64-bit is fully suitable for the goals otherwise. Thanks. Previous Comments: ------------------------------------------------------------------------ [2017-04-10 12:41:19] maggus dot staab at googlemail dot com in https://github.com/nextcloud/server/issues/1707#issuecomment-292937033 it was pointed out why 32 bit builds are used in the first place: "Most SBCs such as Raspberry Pi and Odroid devices still rely on 32 Bit. Therefore this change is a real big thing for those." ------------------------------------------------------------------------ [2017-04-09 09:52:56] spam2 at rhsoft dot net the better question is why is PHP on 32bit limited that way? couldn't it use longint as other applications do? ------------------------------------------------------------------------ [2017-04-09 09:47:48] maggus dot staab at googlemail dot com As userland workaround exists for this exists I guess a builtin handling of such files would/should also work? ------- Quote: Got it working with following patch: /www/nextcloud/3rdparty/sabre/http/lib/Sapi.php@78: while (!feof($body)) { // stream_copy_to_stream($body, $output, $contentLength); fwrite($output,fread($body,8192)); } Instead of copying entire file at once, it copies chunks of 8MB Bit crude, but the concept works :) Based on: http://php.net/manual/en/function.stream-copy-to-stream.php#98119 ---------- See https://github.com/nextcloud/server/issues/1707#issuecomment-288890497 ------------------------------------------------------------------------ [2017-04-09 09:34:39] maggus dot staab at googlemail dot com Description: ------------ stream_copy_to_stream() expects the 3rd arg to be a integer which limits its max value on 32 bit builds. This means some real world use cases dont work because the MAX_INT is not big enough to handle 4GB+ filesizes. Could we handle the arg like a string to support "huge files" on 32 bit php? https://github.com/nextcloud/server/issues/1707#issuecomment-288890497 Expected result: ---------------- Copy of streams with filesize >= 4gb should be supported Actual result: -------------- stream_copy_to_stream() expects parameter 3 to be integer, string ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74395&edit=1