Could you please check AppVeyor, it seems that the broken tests are related to this patch ?

a test case is failing though

IMO, one trailing slash is not a bug (I definitely would say that it is good practice to have it there!). The bug is reproducing the slash multiple times.

Furthermore, it is not an implementation detail. To me, the finder is a complete blackbox, actually. I never studied the code, to be honest, so, in fact, I cannot know any implementation details. It is like a function that I call - I use the results without caring how it came about. For example, the function double(x) = 2 * x that becomes double(x) = 2.0 * x - changing the return type from int to float. (Do not take this comparison too seriously, it's more of a metaphorical nature). Suppose there is no explicit contract that the return type of this function is an int, then there might be code implicitly building on that fact, without it ever being stated anywhere. For me, that about sums up the problem I have with that kind of change. To me, it's not an implementation and definitely not a bug that a path contains one(!) trailing directory separator. That might be a matter of opinion though.

I'd also like to point out that my life goes on whether this PR is merged or not - it's more a question of principle that we are discussing at the moment.

In essence, we can agree that not ensuring that a path ends (or doesn't end) with a slash (whatever the expected behavior is) is careless and dangerous. But it happens - and when it does, then changing the current behavior might come unexpected to some users. The only thing I can ask for is careful thought about the consequences - advantages and disadvantages alike.

About the trailing slash or not and why I made this PR:

During some trainings, I use to make a simple exercice: use the console and the finder to list all PHP files in a directory.

<?php

namespace App\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Style\SymfonyStyle;
use Symfony\Component\Finder\Finder;

class FinderExerciseCommand extends Command
{
    protected static $defaultName = 'app:finder:exercise';

    protected function configure()
    {
        $this
            ->setDescription('Finder playground')
            ->addArgument('dir', InputArgument::REQUIRED, 'Le dossier a scanner')
        ;
    }

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $dir = $input->getArgument('dir');

        $files = Finder::create()
            ->in($dir)
            ->name('*.php')
        ;

        $io = new SymfonyStyle($input, $output);
        $io->listing(iterator_to_array($files));
    }
}

And before the patch, here is output of the following command: bin/console app:finder:exercise src/:

 * src//Command/ExerciceCommand.php
 * src//Command/DoctrineExerciseCommand.php
 * src//Command/FinderExerciseCommand.php
{...}

Did you notice the double /? To me it's a bit ugly.
The same "error" occurs in PHP-CS-fixer. For example:

$ php-cs-fixer fix src/ 
Loaded config default.
   1) src//Command/FinderExerciseCommand.php

@lmanzke PHP itself will never return a trailing slash for APIs returning a directory name (dirname, SplFileInfo::getPath, __DIR__ etc...). So writing your code in a way not adding the separator in the concatenation is actually relying on an implementation detail here (if you don't rely on it, you would be adding a separator in the concatenation to be safe)

The argument of consistence with PHP makes sense, although some of its design choices might be questionable in some instances ;). But that's besides the point, not the right place and time to discuss this rather semantic matter ;).

It may be questionable, but it's really common to not add the trailing slash in the unix philosophy.
Some sample:

>[/home/gregoire] readlink -f dev/
/home/gregoire/dev

>[/home/gregoire] ll dev/
total 24K
drwxr-xr-x 51 gregoire gregoire 4,0K Jan 10 15:56 debug
{...}

>[/home/gregoire] basename dev/
dev

>[/home/gregoire] dirname dev/
.

If you use low level tools like strace the trailing slash is always omitted.

And IIRC, Python, Ruby, ... omit it too.

Anyway, as you said, it's not the place to discuss about PHP design choices ;)

Now Symfony is just consistant with PHP and unix philosophy

In this instance, it makes perfect sense. Thank you.

We're still investigating, but it seems like this breaks updates in Bolt too. First tests indicate adding "symfony/finder": "^2.8, !=2.8.37" in composer.json resolves the issue.

@lmanzke @fabpot

foreach (Finder::create()->dir()->in($dir) as $dir) { $file = $dir.$file; }

This code never worked, so there is no need to discuss whether it should work from a bc promise perspective.

The found directories never contained a trailing slash.

This behavior is on par with native PHP code like:

foreach (new \DirectoryIterator(__DIR__) as $fileInfo) {
    if ($fileInfo->isDir() && !$fileInfo->isDot()) {
        echo $fileInfo->getPathname() . PHP_EOL;
    }
}

Output (__DIR__ in this example is Symfony main repo folder):

...
/Symfony/symfony/src
/Symfony/symfony/vendor

Also no trailing slash on found directories.

Let's look at the symfony/finder counterpart of that code:

$finder = \Symfony\Component\Finder\Finder::create();
$finder
    ->directories()
    ->depth(0)
    ->in(__DIR__);

foreach ($finder as $item) {
    /** @var \Symfony\Component\Finder\SplFileInfo $item */
    echo $item->getPathname() . PHP_EOL;
}

Output:

...
/Symfony/symfony/src
/Symfony/symfony/vendor

Same output, no trailing and no duplicate slashes, all good.

But if we now change the input directory to have a trailing slash, we get different result with finder compared with native PHP iterator:

foreach (new \DirectoryIterator(__DIR__.'/') as $fileInfo) {

Output:

/Symfony/symfony/src
/Symfony/symfony/vendor

->in(__DIR__.'/');

Output:

/Symfony/symfony//src
/Symfony/symfony//vendor

If I understand @lyrixx correctly, it was their intention to fix exactly that, not having duplicate slashes here.

The fix however (applying realpath to the complete resulting path in SplFileObject), introduced an unwanted side effect:

foreach (new \DirectoryIterator(__DIR__.'/../symfony/') as $fileInfo) {

Output:

/Symfony/symfony/../symfony/src
/Symfony/symfony/../symfony/vendor

->in(__DIR__.'/');

Output:

/Symfony/symfony/src
/Symfony/symfony/vendor

The unwanted side effect is, that the base path (search dirs) was normalized (using realpath) as well.

That side effect obviously broke quite some userland code, most likely because this code assumed that the resulting found paths have the same prefix as the given input paths.

I'd argue that this indeed is a BC break that needs a revert, especially also because the introduced behavior differs from native PHP implementation and also because $fileInfo->getPathname() effectively became an alias to $fileInfo->getRealPath(), because getPathname also returned the realpath. it does not make much sense to have two getters returning the same values in all cases.

That is why I trimmed the input values to in() in the PR I proposed

This approach keeps the input/base path intact, but avoids having duplicate slashes in the results in case the input value had a trailing slash. (Which, again, is what @lyrixx intended to fix).

Hope that clarifies what happened and how (I think) it should be fixed.

#26763 should fix the issue.

Actually I found out that the code sample provided by @fabpot indeed never worked. The problem was the getPath() method on returned SplFileInfo objects.

@Imangazaliev can you elaborate on that? What is your problem exactly with getPath? Still having unwanted slashes or non-symlink files?

Actually the slash was there at the end when calling getPath() on an SplFileInfo returned by finder. Now it is not there. While this is consistent, it caused some hidden problems which are now fixed :).

@lmanzke are you talking about the latest release (4.0.8) or the previous one? (4.0.7)

And can you provide the exact code you used, which broke (or still breaks?) for you?

I will get back to you, I'm just very busy at the moment :).

I think there might be a "real" BC break for those trying to list the contents of an FTP root directory. It seems that the trailing slash is required in this case.

See #27423

I think there might be a "real" BC break for those trying to list the contents of an FTP root directory. It seems that the trailing slash is required in this case.

See #27423

It was already fixed and released as bugfix releases for all branches. ;-)

@DanielRuf thanks for the hint.

Unfortunately, I cannot find the mentioned bug fix in the code and I am still getting the error using the latest 4.0 Version (4.0.11).

Or am I missing something?

@jfmaeck see #26849

Hi @DanielRuf as far as I can tell, the bug with the ftp root directory which requires the now stripped slash was released in #26849, not fixed.

Imo this is not a regression and how it should work now. See the complete history of this issue here.

OK, but how can I get the previously working (and documented) example of querying the contents in an FTP root directory fixed?

        $finder = new Finder();
        $files = $finder->files()->in('ftp://speedtest.tele2.net/');
        foreach ($files as $file) {
            var_dump($file);
        }

Or is this use case no longer supported? If that is the case then at least the documentation should be updated accordingly. It currently reads:

always add a trailing slash when looking for in the FTP root dir

(see https://symfony.com/doc/current/components/finder.html)