Description

I am running Mac OS X 10.6 using both MAMP and Apple Servers. The problem was found in the Worpress-MU code but the error is also in Wordpress.

The problem was traced to the @ftp_rawlist call in the function dirlist() in the class file class-wp-filesystem-ftpext.php. The @ftp_rawlist call preforms an ftp LIST command and is supposed to return a listing of a directories contents, including any folders in the directory. It was returning a boolean false instead of an array of file/folder listings.

May have jumped the gun there, I see you're reporting this in 2.9.1.. In which case, I'm still confused why that error is thrown, but its not related to ZipArchive :)

Yes, it does not seem to be a zipping problem, In fact, the .zip file gets downloaded and unzipped properly into a temporary folder named "the-new-theme-name.tmp" but then when the system goes to move the unzipped files it tries to access the temporary folder to get the files/folders contents. That's when the $list=@ftp_rawlist function fails. The function does not return an error (any error that might be produced is not tested for anyway), so the system just runs along as though it did receive the array of directory contents until the error is thrown somewhere else, do not remember where it was thrown but it was much further along in the code....

My error there.. Seems that "Incompatible Archive" is also the error for the source directory having 0 files.. Which is why its rawlist() causing the problems..

Removing -a will fix this, But also means that any "hidden" directories will not be listed, which can be a problem when people want to overwrite a SVN checkout with the plugin upgrader for example.

I think it'd also have an effect on the return data, Given that we dont always check to see if a folder exists before listing its contents (Saves on the number of FTP calls needed), we'd probably have to expand the code related to ftp_rawlist returning nothing.

Not having access to a Mac doesnt help me debug/work around this issue.. Macs are pretty common amongst some IT crowds, so i'm surprised this hasnt occured before if its a widespread issue.

I'm reducing the Severity of this, since its not a regression from a previous version, and it seemingly only affects a smaller group of hosts.

I am not sure as I am new to wordpress but the hidden directories were not being used anyway. After the rawlist call dirlist() builds an array to return to its caller and when it builds the array it ignores the hidden files. See below:

So, in addition to fixing up the problem with returning nothing, (actually dirlist() returns a boolean false instead of an empty array and this causes a PHP Warning to be issued when the boolean is used by a following array_keys call that is trying to use what it thinks is a returned array) I guess you would have to test for how the hidden files are used when people want to overwrite with a SVN checkout. I need to study PHP and Wordpress more so if you like (and I have the Mac) I can pursue the issues. You would have to point me in the right direction though as I do not have the SVN stuff setup yet (pointing me to some SVN knowledge would help) and another other suggestions you may have...

Yes, I tried chdir also but found it caused path errors later in the code. I fixed that by saving the current directory, then used chdir, and then restored the current directory. But I abandoned that approach and just took out the -a because if you look further down in the dirlist() function they skip the hidden directories anyway and they are never used.

The above section of code will skip over the special directory listings for current dir and parent dir. This is commented wrong. Since there are more hidden files than just these two.

if ( ! $include_hidden && '.' == $entryname?[0] )
continue;

And this would skip the remaining hidden files (files starting with a .) if $include_hidden is false, which it's not. It's set by default to true in the function/method definition, and a different value is not passed in this case.

I thought about saving the current dir and resetting it after the operation, but if I remember correctly, when I tested the value of PWD before the operation, it returned an empty string.

I have not seen any issues which I can blame on this changeset since the last bug 5 weeks back, I'll leave this open until RC time, If nothing comes up in RC1, I'll assume that this hasnt broken anything & can close it then.