[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):

 Clarifying: One of the reasons SearchWP failed to upgrade was not only was
 the `zip` filename large, the plugin uses a deeply nested directory
 structure as well. So a reasonable-length filename can still keep windows
 from creating a new directory if the total character length of the path is
 over 247 characters:

 {{{
 C:/wamp/www/example/wp-content/upgrade/REASONABLE_LENGTH_ZIP_FILE_NAME-
 d8310f/
 20-character-dirname/20-character-dirname/20-character-dirname/
 20-character-dirname/20-character-dirname/20-character-dirname/
 20-character-dirname/20-character-dirname/new
 }}}

 Would also fail.

 In this case, WordPress would have no knowledge at the time of the
 `wp_tempnam()` call that the code using the returned result would be
 adding hundreds of additional characters to the path.

 Welp.

 Perhaps there is nothing which could really be done other than make it
 clear to authors that deeply-nested directory structures combined with
 long filenames means they're flirting with failure.

 I do not know enough about windows (or `mkdir`) to know if this limit is
 always true, or only if using absolute paths. If the latter, it might be
 able to be skirting by calling `mkdir` using a relative path repeatedly,
 but I have no idea.

 **In sum:** This is an actual problem, but I have no idea what an actual
 solution might be. My max-length solution would probably catch all but the
 edge-cases of edge-cases, and would have caught the actual error in this
 particular instance.

 At the very least, documentation? And perhaps something in the repository
 review process which flags deeply-nested file structures and lets the
 developer know they're treading on dangerous ground?

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