Opened 11 years ago
Closed 10 years ago
#29672 closed defect (bug) (duplicate)
Direct put_contents fails during plugin installation because filename exceeds MAX_PATH on Windows.
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Priority: | normal | |
| Severity: | normal | Version: | 4.0 |
| Component: | Upgrade/Install | Keywords: | |
| Focuses: | Cc: |
Description
I recently installed WordPress on Windows 8.1 Pro. I tried to install the 'iThemes Exchange' plugin. My default install directory was 'C:\Users\Username\Documents\My Web Sites\wordpress'
The plugin used many nested folders. When the plugin installation failed WordPress reports 'Could not copy file.' with the filename. I imagine this must be a common issue, but I found the error reporting lacking in detail. It was not clear that I could not install the plugin because ultimately the temp. filename in the wp-content/upgrade dir exceeded Windows MAX_PATH.
I'm not sure of how this could be fixed. Possibly WordPress could detect your "base" directory length and examine the longest required directory length for a plugin's installation. Maybe plugin development could require folder dir lengths do not exceed a given length? I'd be willing to put together a change here if anyone has any ideas on how best to handle this.
Thanks for the report willwire. Sorry it took so long for someone to respond.
I don't have a windows box, so I have no way of testing this or working on it.
As a workaround, it looks like acording to https://support.microsoft.com/en-us/kb/177665 you can setup access to these files and folders through a local redirection ("net use" or "subst") of the same share/folder that the network clients access across the network.
I don't know if this is something we are going to be able to fix in WordPress though. It seems to be an underlying issue with how windows internally stores folder names.