Whoop - I added the PR to the wrong issue. The PR is for something else entirely, but apparently there is no way to delete it.

Okay - I understand what is happening, but can't tell what the 'correct' behaviour should be.

The code is assuming that DirectoryIterator will return objects alphabetically. It isn't doing so. Instead the file entries are listed alphabetically within 'blocks', but the blocks are ordered in reverse.

i.e. the first entry in the cloned iterator is SplObjectStorage_getHash.phpt, while the first entry in the original iterator is array_001.phpt


The full output is https://gist.github.com/Danack/e9c7ca12958cdd180197.


TL:DR the test assumes that DirectoryIterator always returns values in the same alphabetical order, it doesn't. And so the test fails sometimes.

I've deleted the link to the wrong PR.

Can't reproduce the failure described here. Both of the tests run fine whether run through `php run-tests.php` or not, and whether run under valgrind or not.

5 years have passed, a lot has changed, and whatever was causing this bug has probably been fixed. The ticket should be closed.

Hi Alex,

I'm pretty sure the bad assumption is still there: https://github.com/php/php-src/blob/826a7456717b8fab22d43deedf7b6ab1b1f426be/ext/spl/spl_directory.c#L371

Below is an example of how cloning a directoryIterator doesn't result in an object that is actually a clone


<?php

$a = new DirectoryIterator(__DIR__);

$baseName = basename(__FILE__);
$found = false;

while($found == false) {
    $a->next();
    if ($baseName === (string)$a) {
        $found = true;
    }
};

file_put_contents('created_file.txt', 'feel free to delete');


$b = clone $a;
// Cloning should result in same object, right?

if ((string)$b != (string)$a) {
    // surprise!
    // output is "file 1: dir_bug.php file 2: created_file.txt"
    printf(
        "file 1: %s file 2: %s",
        (string)$a,
        (string)$b
    );
}

unlink('created_file.txt');

dit_004.phpt has been improved[1] in the meantime, and
dit_005.phpt has a respective comment[2].  So the issue that
iterating over modified directories may not yield stable results
is known.  To explain: DirectoryIterator uses readdir()[3] under the
hood, and POSIX states:

| If a file is removed from or added to the directory after the
| most recent call to opendir() or rewinddir(), whether a subsequent
| call to readdir() returns an entry for that file is unspecified.

Even worse, POSIX also states:

| The readdir() function may buffer several directory entries per
| actual read operation; […]

So yes, obviously DirectoryIterator clones may not behave as expected.
I don't see a way to fix this, short off prohibiting cloning such
objects altogether.

Regarding the ordering: this looks strange to me, since POSIX
mandates (emphasis mine):

| The type DIR, which is defined in the <dirent.h> header,
| represents a directory stream, which is an **ordered** sequence of
| all the directory entries in a particular directory.

While it does not specify which order, the order should not
change, I think.  Anyway, that directory entries are not
necessarily ordered alphabetically is also a known issue, and
either partly documented or tracked by another ticket.

So this issue is best categorized as documentation problem, and
maybe it's worthwhile to improve dit_005.phpt similar to what has
been done with dit_004.phpt.

[1] <https://github.com/php/php-src/commit/0535872b7cd50be8b40ad06154b287749315eb27>
[2] <https://github.com/php/php-src/blob/PHP-7.4.23/ext/spl/tests/dit_005.phpt#L5>
[3] <https://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html>