[wp-trac] [WordPress Trac] #40795: If plugin zip file has very long name, windows systems can fail to upgrade

[WordPress Trac]

#40795: If plugin zip file has very long name, windows systems can fail to upgrade
--------------------------+------------------------------
 Reporter:  rogerlos      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:  4.7.5
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by rogerlos):

 I'm not entirely clear on your question, but:

 * `wp_tempnam()` is in `wp-admin/includes/file.php` at (currently) line
 622
 * The long filename which caused the upgrade to fail was created as part
 of the automatic WP upgrade process, I assume based on the zip provided to
 the plugins repository

 I am not an expert on this bit of WordPress, but as far as I can
 determine, `wp_tempnam()` is used to avoid naming conflicts in processes
 which might touch a number of files, or write to a common directory. It
 does this by adding a hyphen + six random characters to the filename.
 (Sorry for restating stuff you probably already know!)

 So, in theory, it should not matter what WP returns from this function, as
 the "tempnam" is just that, a temporary name to use for the duration of a
 single process, or be passed as a parameter to other processes. WordPress
 itself seems to think six characters of noise is enough to avoid
 conflicts.

 I would suggest that code which attempts to parse a returned value from
 `wp_tempnam()` is not adhering to best practices. The code should already
 know what was passed to that function, or if it's "downstream" code, the
 original name should have been passed as a parameter.

 As far as I can tell, the only things which might break if a length limit
 was enforced are such situations. But I can't say that with any authority.

 Rather than enforcing a set limit, perhaps `wp_tempnam()` can add a "this
 is really huge" test and only truncate those filenames that fail it. That
 test would have to be something like this pseudocode:

 {{{
 $fail = strlen( $path_on_disk ) + strlen( $filename ) >= $max_path[
 $server_os ];
 }}}

 But that seems like a lot more work than just deciding on an upper limit,
 as you now have to detect operating systems, find out what their limits
 are, etc.

 Another option would be to simply return `false` or `null` (or throw an
 exception) if the result of the calculation is longer than whatever the
 arbitrary limit is.

 (An alternative would be to establish an arbitrary but healthy filename
 length limit as a max for developers adding files to the WP repository. 64
 seems like plenty to me, but even 128 would have allowed SearchWP to
 update.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/40795#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform