`fopen($path, 'x')` should not succeed when called twice

[0b10011]

The x mode for fopen() should fail when called twice, as the first call should create the file.

$a = fopen('fs://test.flag', 'x');
$b = fopen('fs://test.flag', 'x');
if (is_resource($a)) {
    echo 'a';
    fclose($a);
}
if (is_resource($b)) {
    echo 'b';
    fclose($b);
}

Expected result:

a

fopen(): failed to open stream: File exists

Actual result:

ab

[Lewiscowles1986]

Relevant PHP documentation for behaviour of fopen

'x' | Create and open for writing only; place the file pointer at the beginning of the file. If the file already exists, the fopen() call will fail by returning FALSE and generating an error of level E_WARNING. If the file does not exist, attempt to create it. This is equivalent to specifying O_EXCL|O_CREAT flags for the underlying open(2) system call.

https://www.php.net/manual/en/function.fopen.php

I think the issue there is the need to have some distributed lock system. Technically once your filesystem is on a network locks need to be enforced on the network, which they cannot be using some of the flysystem backends, which don't support file/object-level locking.

A Person could add a redis or similar fast network key-value store which supports locking, but then you have a whole new set of dependencies and class of problems to solve.

I'd recommend perhaps the addition of a locking interface to use when this is required; but then marking this as fixed or wontfix because there can be no generic one-size solution to this.

[0b10011]

I think the issue there is the need to have some distributed lock system. Technically once your filesystem is on a network locks need to be enforced on the network, which they cannot be using some of the flysystem backends, which don't support file/object-level locking.

When using those backends that don't support file/object-level locking, any call to fopen($file, 'x') (or other locking flags) should fail as if the filesystem couldn't be read I would imagine. It should not pretend to succeed.

[Lewiscowles1986]

Seems like PHP via flock could be interpreted to agree.

Note:

May only be used on file pointers returned by fopen() for local files, or file pointers pointing to userspace streams that implement the streamWrapper::stream_lock() method.

hints about the interface implementation are then given

Warning
On some operating systems flock() is implemented at the process level. When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!

flock() is not supported on antiquated filesystems like FAT and its derivates and will therefore always return FALSE under these environments.

However... Crucially I think perhaps the following gives a hint at a more permissive interpretation.

When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!

There are already examples of where flock the primary file-locking mechanism of the language falls apart on same-server. To suggest a distributed implementation should handle the intricacies is problematic.

The two places this would make sense to complain to would be flysystem, or PHP