On Mon, Jun 1, 2020 at 1:48 AM Theodore Brown
wrote:
> On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei
> wrote:
>
> > the Attributes RFC was rather large already, so a few things were left
> > open or discussions during the vote have made us rethink a things.
> >
> >
fsync() does not *guarantee* data has been persisted because no software
mechanism which exists can do that. It is however the *best assurance* we
can have that data has been physically persisted by the time the function
returns.
fsync() is the best operating-system level assurance we can get
Am 01.06.2020 um 18:56 schrieb David Gebler :
> It seems to me an odd oversight that this has never been implemented in PHP
> and means PHP has no way to perform durable file write operations, making
> it inherently unsuitable for any systems requiring more intensive I/O,
> mission critical logs,
Just to add and clarify; operating systems have their own internal write
buffers. When you call fflush() you are saying "immediately flush this data
from my program buffers to the operating system".
When you call fsync() you are saying "immediately flush this data from my
program buffers to the
No, fflush will flush the PHP application buffers out to the operating
system, it does in contrast to fsync not provide a guarantee the operating
system will immediately persist to the underlying storage device.
On Mon, 1 Jun 2020, 18:49 Dennis Birkholz, wrote:
> Hello David,
>
> isn't fflush
Hello David,
isn't fflush exactly this:
https://www.php.net/manual/en/function.fflush.php
Greets
Dennis
Am 01.06.20 um 18:56 schrieb David Gebler:
> Exactly as the subject says, I would like to propose an RFC for adding an
> fsync() function for file resources, which would in essence be a thin
Exactly as the subject says, I would like to propose an RFC for adding an
fsync() function for file resources, which would in essence be a thin
wrapper around C's fsync on UNIX systems and _commit on Windows.
It seems to me an odd oversight that this has never been implemented in PHP
and means
Hi, having relaxed the DMARC rules, please let me know if this message
was more successful than those previously sent from ja...@givoni.dk
Thanks!
On Sat, May 30, 2020 at 1:20 AM Ben Ramsey wrote:
>
> > On May 29, 2020, at 18:01, Reindl Harald wrote:
> >
> >
> >
> > Am 30.05.20 um 00:58 schrieb
On Mon, 1 Jun 2020 at 00:48, Theodore Brown wrote:
>
> Having a distinct token for attributes would entirely avoid the issues
> of having to modify multiple lines when adding/removing attributes, as
> well as confusion with shift operators and comma-separated attribute
> arguments. E.g. the RFC
