Ability to disable tmp caching of phar contents

[dktapps]

Description

It's not clear to me what the point of caching phar contents is. In a world where opcache is used, it shouldn't be necessary to cache the phar contents anyway, except perhaps the occasional data file.

In addition, since different threads / processes don't share phar caches, /tmp can get very crowded with lots of files caching near-identical data.

I maintain a long-running application in which autoload time is not a concern, but the hogging of tmp space is a problem for my users. There doesn't seem to be a way to stop ext-phar from caching things read from phars.

[dktapps]

Additionally the cache files don't seem to go away when unseting the phar, which seems weird and also prevented me from solving this with a custom stream wrapper.

[crrodriguez]

in a modern OS it should be enough to remove this caching but set POSIX_FADV_WILLNEED though this all probably only matters (if at all) at all with slow storage..
Note that nowadays /tmp is backed by virtual memory..

[dktapps]

in a modern OS it should be enough to remove this caching but set POSIX_FADV_WILLNEED though this all probably only matters (if at all) at all with slow storage..

Only files that were compressed in the phar are cached on /tmp, so I don't think the storage speed is the concern. Uncompressed files are read directly from the .phar.

[dktapps]

Seems like the awkward design of the stream wrapper ops makes the tmpfile a necessity for handling compressed files within phars. Too bad PharFileInfo doesn't have any way to get the offset within the .phar file or I could probably solve this with gzopen() in PHP ...

[crrodriguez]

It isn't awkward..it is just old .. a proper generic decompression library like libarchive wasn't an option back then. Today it could be just a libarchive filter/format and PHP just evaluates the code..