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

the better question is why is PHP on 32bit limited that way?
couldn't it use longint as other applications do?

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."

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.

> for date it's still ok

well, in 2038 it's too late, you likely have to deal with timestamps pointing in the future years before...

> 32-bit PHP is strict and the key is simplicity and performance

someone needs to show me a real world usecase in 2017 where the operating system is 32 bit and performance really matters - playing around on a Raspberry is hardly performance relevant beause it can't stand concurrency load anyways

@spam2 well, 2017 and still someone cares about 32-bit :) But joke aside, you can simply benchmark 64-bit math on 32-bit platform, to see diff. It can also be hardly  worth the efforts to do big refactorings or even tricks, where modern RPI or others ship with a 64-bit processor, and eventually 32-bit will die out same way it did already for desktops, etc. 

Thanks.

Well, this should probably wait on the outcome of bug #54902
anyway, because the other ticket is about inconsistencies
regarding files between 2GB and 4GB.

The other ticket has been changed to doc issue, and given the
drawbacks, technical difficulties and limitations to implement
this, I'm closing this ticket as WONTFIX.

If anybody is still interested in beeing able to copy large
streams on 32bit architectures (or more generally 64bit integers,
or full LFS), please pursue the RFC process[1].

[1] <https://wiki.php.net/rfc/howto>