On Tue, Jul 8, 2014 at 2:31 PM, Ivan Enderlin @ Hoa
<ivan.ender...@hoa-project.net> wrote:
>
> On 08/07/2014 11:08, Julien Pauli wrote:
>>
>> On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa
>> <ivan.ender...@hoa-project.net> wrote:
>>>
>>> On 13/06/2014 16:20, Julien Pauli wrote:
>>>>
>>>> - One that relies on ftruncate() , and adds a <bool>$use_fallocate
>>>> flag https://github.com/jpauli/php-src/tree/fallocate_flag
>>>>
>>>> Please, note that the latest proposal requires patches in different
>>>> extensions, as I changed a PHP_API function signature.
>>>>
>>>> I don't know if Windows can support that. Pierre, Anatol ? :-)
>>>>
>>>> Tests are beeing written at the moment.
>>>>
>>>> I didn't implement this is user stream handlers, as this really is a
>>>> low level implementation design that is kind of useless for usage in
>>>> user streams.
>>>>
>>>> Thoughts ?
>>>
>>> If the first one is used, please, consider exposing it on the user-land
>>> of
>>> stream wrappers (exemple: `stream_allocate`) if possible.
>>
>> I find it very useless as user stream already have the ftruncate
>> exposed to them.
>
> Hum no, this is very useful actually. A stream wrapper can be used to
> represent a file somewhere else, imagine `ntfs://`, `smb://`, `aws://`,
> `ftp://`, `afp://` etc.
>
>
>
>> The difference between ftruncate and fallocate is meaningless in userland.
>
> If `fallocate` is proposed in the user-land, then it will be logical to have
> it in the stream wrapper API. That's it :-).

I admit that it would be nice for consistency, however I wonder how
users will interpret the difference between ftruncate and fallocate.

Julien

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to