class-wp-filesystem-base::search_for_folder returns incorrect path

[cgastrell]

Intro

I got myself in an unusual situation, so this bug will oddly be duplicated. Worth a ticket though.

search_for_folder gets cut off in the wrong directory if a folder name is duplicated along the path.

Example

/var/www/domain/htdocs/wp_install

will work nice

/var/www/domain/www/wp_install

will fail

Case

My situation is like this (in case i'm not being completely clear, pardon my english):

live site path

/var/www/domain/www : working site

test site path

/var/www/domain/test : working site installation duped and working

path to ftp root

/var/www/

Every operation via ftp (automatic updates, plugin delete, theme install, plugin install) done on the test site falls on the directory of live site

When search_for_folder loops through the path parts (0=>var,1=>www,2=>domain,3=>www), as there are two path parts with the same name, it will be fouled into the first one. I don't know how else I could explain it, I'm not that good. Turning $this->verbose to true and adding print_r('key ' . $key .'<br />'); at the begining of the foreach allowed me to understand how this was happening (will attach). My wp is in spanish, so, in the image, when it says 'Cambiando' means 'Changing to' and 'Encontrado' means 'Found' (verbose messages).

Hope somebody pick this and come up with some fixing.

[cgastrell]

search_for_folder verbose output with $key printing

[SergeyBiryukov]

Confirmed.

[dd32]

I believe #20652 is the same thing.

It feels like a off-by-1 race error, or perhaps, a string position lookup that's looking too far behind, but I haven't had a chance to duplicate it, or trace it myself.

[cgastrell]

I don't know how to graphically explain this, I just know it's wrong :)

Take the array from the attached image, my working path:

• [0] => 'var',
• [1] => 'www',
• [2] => 'domain.com.ar',
• [3] => 'test'

Then the foreach loop takes every item in the array and tries to guess the actual path, with a trial and error check with exists for the path. The thing is that, for every item in the array, the loop tries to build the path from scratch.
So, in the first run, the loop looks for the var directory from root. Fine, finds it and stablishes it as a starting point for the next loop.

/ + var

exists => stablish new starting path: /var

Second and third item goes fine, as path exists and is correct path guessing.

/var + /var

exists = false, next

/var + /www

exists = true, stablish starting path, next loop

Third run:

/var/www + /var

exists = false, next

/var/www + /www

exists = false, next

/var/www + /domain.com.ar

exists = true, stablish starting path, next loop

As the fourth run occurs, the issue arises:

/var/www/domain.com.ar + /var

exists = false, next

/var/www/domain.com.ar + /www

exists = true, but the path found here is only found by mere coincidence of using a directory with a same name twice. My installation was at /var/www/domain.com.ar/test but it happens that I had my original installation at /var/www/domain.com.ar/www as the working live site, so it finds it but is wrongly guessed.

This is something not carefully thought, and I say this without any offensive intention, you just don't go around guessing paths like this. I know my case is quite rare because of the way I arrange my directories, but this could have lead to a catastrophic scenario in a shared hosting. Mine es merely a multiple vhosted apache.

Hope this helps understanding the issue.

[dd32]

In [21221]:

WP_Filesystem: Correct a rare case where the FTP directory will be detected incorrectly when the final path token exists higher in the chain, for example /x/x/Z/x/Z/ would be detected as /x/x/Z/. Fixes #20934

[dd32]

The cause here was that it was using the Value of the array to detect the end element of the array, when the value exists in multiple locations in the array, it would erroneously think it had found the final path. The fix was to use the index of the array instead to determine the position in the array.

[cgastrell]

Replying to dd32:

In [21221]:

WP_Filesystem: Correct a rare case where the FTP directory will be detected incorrectly when the final path token exists higher in the chain, for example /x/x/Z/x/Z/ would be detected as /x/x/Z/. Fixes #20934

Great news to read, thanks and congrats! Will wait for 3.5, in the meantime, is it too much to ask you to paste corrected code here so I can do an early implementation of it? Thanks.

[SergeyBiryukov]

You can see it in the changeset: ​http://core.trac.wordpress.org/changeset/21221

[dd32]

Evidently this also required [21222] to fix it. Noting it here for future reference.