Installers Tab is whited out when extracting certain mods

[Infernio]

From https://github.com/wrye-bash/wrye-bash/issues/380#issuecomment-538708431 by @BeermotorWB:

Update testing with the 307.201910052118 WIP:

Acquired: Tempered Skins for Males - Nude Version-7902-1-30-1550177905 since this was the previous test file.

Test One:

• Moved to F:\SteamLibrary\steamapps\common\Skyrim Special Edition Mods\Bash Installers
• Unpack to project
• Expected: Unpack and CRC check to full mod path
• Observed: Mod called 7zip, raised unzip dialog box. CRC check. Project did not appear. Relaunching WB displayed grey diamond icon. Not all files present.

Test two:

• Unzipped (7zfm.exe) to F:\Unzip\
• Copied files into F:\SteamLibrary\steamapps\common\Skyrim Special Edition Mods\Bash Installers\Tempered Skins for Males - Nude Version-7902-1-30-1550177905\
• Launched WB
• Expected: Installer tab populates, displays package
• Observed: Switched to installer tab. Installer tab did not populate.

Test three:

• Created empty project in WB for Tempered Skins
• Double-clicked new project to open Win Explorer window at that directory on FS.
• Double clicked "Tempered Skins for Males - Nude Version-7902-1-30-1550177905" to launch the ,7z file in 7zFM.exe.
• Drag+drop unzipped files out of 7z file to project directory explorer window.
• Received error message from 7zfm that path was too long, confirmation dialog to skip files.

So this really the stock crappy NTFS 260 character limitation.

All hope is not lost however. Apparently you can exceed 260 characters under certain circumstances. See:

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file

https://www.programcreek.com/python/example/82687/win32api.GetVolumeInformation

Just for grins I applied a registry edit to enable long paths. It did not work after a reboot. This did nothing to overcome the issue when running 7zip outside of WB, so it could be a limitation of 7zip.

[Infernio]

For anyone crawling through the history, the bug that this issue was previously about was fixed by fa583a27d653d3d3fe5f3f80cf8410c82489b2c9.

[Infernio]

@BeermotorWB Let's take this issue: https://github.com/wrye-bash/wrye-bash/issues/380#issuecomment-538708431 to right here. The TypeError: String or Unicode type required issue turned out to be unrelated and easily fixed.

[BeermotorWB]

@Utumno and @Infernio :

We discussed this Windows path issue in the Discord dev chat and I did some research into work-arounds. According to several pieces of information I found it is possible to use long paths with Python 2.x and 3.x.

Braindump:

Python JIRA on the topic: https://bugs.python.org/issue27731

Article on bypassing the path length limitation: https://www.burgaud.com/path-too-long

Stack Overflow discussions: https://stackoverflow.com/questions/46113181/how-to-know-from-python-if-windows-path-limit-has-been-removed

https://stackoverflow.com/questions/1365797/python-long-filename-support-broken-in-windows

[Utumno]

Hmmm - I think for now we should disable the whole project and move this to after py3 support, as the https://bugs.python.org/issue27731 is for python 3.6

[BeermotorWB]

@Utumno Just to clarify this work-around has been supported since Python 2.5.

[BeermotorWB]

@Utumno Ok I spoke with @Infernio and looked at the code and I saw the light. I agree this is best done after Py3.

[Infernio]

This should have been closed in 1f84ea8f351bb66b718f76cfa1bb96ca8e2a9003. Closing now (and retagging to 311 milestone, which that commit is included in).