WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 10 months ago

Last modified 10 months ago

#48960 closed defect (bug) (fixed)

failed to open dir: No such file or directory in WIndows

Reported by: eden159 Owned by: azaozz
Milestone: 5.3.2 Priority: normal
Severity: major Version: 5.3.1
Component: Media Keywords: has-patch fixed-major
Focuses: Cc:

Description (last modified by SergeyBiryukov)

After updating to version 5.3.1 on my Window server I got the following error:

Warning: scandir(C:\Windows\TEMP/,C:\Windows\TEMP/): Zugriff verweigert (code: 5) in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: scandir(C:\Windows\TEMP/): failed to open dir: No such file or directory in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: scandir(): (errno 2): No such file or directory in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: array_diff(): Argument #1 is not an array in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: scandir(C:\Windows\TEMP/,C:\Windows\TEMP/): Zugriff verweigert (code: 5) in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: scandir(C:\Windows\TEMP/): failed to open dir: No such file or directory in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: scandir(): (errno 2): No such file or directory in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479 

Warning: array_diff(): Argument #1 is not an array in D:\Data\_iis\intercycle.dev.mxm.ch\wp-includes\functions.php on line 2479

It is trying to access a folder which it does not have access to and it is producing this error.

Attachments (2)

48960.diff (2.8 KB) - added by azaozz 11 months ago.
48960.1.diff (2.9 KB) - added by audrasjb 11 months ago.
Refreshes patch with proper yoda condition

Download all attachments as: .zip

Change History (28)

#1 follow-up: @pikamander2
11 months ago

Does the bug still happen when you disable all of your plugins? (Be sure to make a backup beforehand)

Does your wp-includes folder contain a functions.php file? If so, is it set to the right permissions?

Last edited 11 months ago by SergeyBiryukov (previous) (diff)

#2 @SergeyBiryukov
11 months ago

  • Description modified (diff)

#3 @SergeyBiryukov
11 months ago

  • Component changed from General to Media

#4 in reply to: ↑ 1 @eden159
11 months ago

wp_includes has the functions.php with the right permissions. I cannot disable all the plugins since it is a dev server and other people are working on it as well.

Replying to pikamander2:

Does the bug still happen when you disable all of your plugins? (Be sure to make a backup beforehand)

Does your wp-includes folder contain a functions.php file? If so, is it set to the right permissions?

#5 follow-up: @azaozz
11 months ago

Sounds like this is caused by wp_unique_filename() checking for existing files in the wrong directory: https://core.trac.wordpress.org/browser/tags/5.3.1/src/wp-includes/functions.php#L2473. The warnings can be silenced, but that will "hide" the underlying problem making it harder to find and debug (basically that function doesn't do anything when the directory is not readable).

@eden159 could you give some more details please: when does this happen (during upload, etc.), and if it makes the performed action fail (i.e. an upload would fail).

#6 @azaozz
11 months ago

  • Keywords reporter-feedback added

#7 in reply to: ↑ 5 @eden159
11 months ago

Hi This happens on EVERY page in the ADMIN panel. In the frontend there are no warnings - only in the admin panel and every page.

Replying to azaozz:

Sounds like this is caused by wp_unique_filename() checking for existing files in the wrong directory: https://core.trac.wordpress.org/browser/tags/5.3.1/src/wp-includes/functions.php#L2473. The warnings can be silenced, but that will "hide" the underlying problem making it harder to find and debug (basically that function doesn't do anything when the directory is not readable).

@eden159 could you give some more details please: when does this happen (during upload, etc.), and if it makes the performed action fail (i.e. an upload would fail).

#8 @azaozz
11 months ago

Looking at this further, it seems caused by unreadable temp directory when using wp_tempnam().

In addition wp_tempnam() seem to be called from a plugin that is (perhaps) writing couple of files to the disk on every wp-admin page load. Not sure why this is needed but it's a pretty bad performance.

To fix this and similar cases perhaps the last filename check in wp_unique_filename() should be done only when the file is going to be in the uploads dir. In addition, perhaps scandir() should be silenced as there might be cases where it will fail regardless.

@azaozz
11 months ago

#9 @azaozz
11 months ago

  • Keywords has-patch needs-testing added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 5.3.2

In 48960.diff:

  • Only check for "image sub-size like" filenames when the file will be in the uploads dir.
  • Silence errors in scandir().
  • Fix the unit tests to match.

#10 @slabbi
11 months ago

  • Severity changed from normal to major

This ticket was mentioned in Slack in #forums by clorith. View the logs.


11 months ago

@audrasjb
11 months ago

Refreshes patch with proper yoda condition

#12 @audrasjb
11 months ago

48960.diff looks good to me.
48960.1.diff just refreshes the patch to use proper Yoda condition.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


10 months ago

#14 @newshop
10 months ago

Same here. Happens when updating themes, plugins or translations. Tested with ALL plugins disabled and Twenty Nineteen theme. A friend of mine and other users have the same problem: https://wordpress.org/support/topic/wordpress-5-3-1-error/

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


10 months ago

#16 @azaozz
10 months ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 46965:

Upload:

  • Fix PHP warnings in wp_unique_filename() when the destination directory is unreadable.
  • Run the final name collision test only for files that are saved to the uploads directory.
  • Update the unit tests to match.

Props eden159, audrasjb, azaozz.
Fixes #48960 for trunk.

#17 @azaozz
10 months ago

  • Keywords fixed-major added; needs-testing removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopen for 5.3.2.

#18 @SergeyBiryukov
10 months ago

#49014 was marked as a duplicate.

#19 follow-up: @autotutorial
10 months ago

Hi guys do a great job, I have a suggestion to improve scandir, the code is well commented .. I'm not sure for php 7.4 in doubt I have inserted a comment.
Best wishes for happy holidays and good work.
currently your patch can pass false in array_diff in my example is correct.

<?php
            // Compatibily with open_basedir
            $dir_trim = dirname( '/' . preg_replace( '#^((?:[^:]+:)?(?:\\\\|/))?(.*)$#', '$2', rtrim( $dir, '\\/' ) ) . '/' ) !== '/' ? $dir_default = array( '.', '..' ) : $dir_default = array( '.' );
            $dir_arr = @scandir( $dir );
                if( !$dir_arr ) {
                    //compatibility php 7.4 see https://wiki.php.net/rfc/notice-for-non-valid-array-container
                    unset( $dir_arr );
                    $dir_arr = $dir_default;
                }
             // restore key with start 0 or now array_diff work , previous
             // scandir without variable not remove dot.
             $files = array_values( array_diff( $dir_arr, array( '.', '..' ) ) );
             unset( $dir_default, $dir_arr, $dir_trim );
Last edited 10 months ago by autotutorial (previous) (diff)

#20 in reply to: ↑ 19 @azaozz
10 months ago

Replying to autotutorial:

Thanks for the suggestion but not sure the 7.4/E_WARNING for invalid container read array-access is needed here. According to the PHP docs scandir() returns an array, or false on error. We are only interested if it is an array (i.e. not false) and if there are any actual file names in it.

It is also limited to only look at the upload dir, which is generally always readable/writable, and scandir() is silenced in case there are any other edge cases/errors.

#21 follow-up: @autotutorial
10 months ago

Thanks for your answer, the problem remains that when it is false it must be converted to an empty array for array_diff otherwise there is a warning for the invalid argument .. expect an array, further array_value recreates the keys starting from 0 otherwise the array starts at 2.

#22 @azaozz
10 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 46979:

Upload:

  • Fix PHP warnings in wp_unique_filename() when the destination directory is unreadable.
  • Run the final name collision test only for files that are saved to the uploads directory.
  • Update the unit tests to match.

Props eden159, audrasjb, azaozz.
Merges [46965] to the 5.3 branch.
Fixes #48960.

#23 in reply to: ↑ 21 ; follow-up: @azaozz
10 months ago

Replying to autotutorial:

the problem remains that when it is false it must be converted to an empty array...

Right. The if ( ! empty( $files ) ) checks that.

#24 @azaozz
10 months ago

Everybody having this problem, please test https://wordpress.org/wordpress-5.3.2-RC1.zip asap if possible. Scheduled for release tomorrow.

#25 in reply to: ↑ 23 ; follow-up: @autotutorial
10 months ago

Replying to azaozz:

Replying to autotutorial:

the problem remains that when it is false it must be converted to an empty array...

Right. The if ( ! empty( $files ) ) checks that.

I got carried away by the enthusiasm I didn't see the change in the patch and I looked at it ten times I realized it when you closed the topic .. sorry.

#26 in reply to: ↑ 25 @azaozz
10 months ago

Replying to autotutorial:

NP, thanks for looking at this! Always nice to have more people checking things :)

Note: See TracTickets for help on using tickets.