The current 12.6 release has a problem with expanding long paths. On the example below is one MBR drive that works properly as well as a GPT example that does not expand in the directory tree beyond three folders that reach the max_path limit, even though you can still see the final folder nested on the right.
I have the Windows registry change made for handling long filenames.
Opus shouldn't care if a drive is MBR or GPT. It does not process the raw partitions or anything that low-level. It will treat both those drives the same, although the operating system may not.
What happens in File Explorer?
As a general note, the registry setting to enable really long paths will not make them work everywhere. Large parts of the Windows APIs, as well as many libraries and programs, still have MAX_PATH limits which the registry setting cannot do anything about. Opus aims to support really long paths at least enough that you can view folders that use them and copy/move/rename and delete files in them (not always with the recycle bin, as it may have issues with long paths), but there will be some things which don't work, for the same reason that the registry setting won't make everything in Windows work with them. (Indeed, that is probably why it is still a registry setting and not the default.)
Extracting RARs, for example. Should the users take a proactive instance and start documenting which aspects of Opus don't support the max_path override and start begging the upstream library developers for change or should the users assume that Opus' developers already know of these and already asked that the upstream library developers update their code?
That one is probably on our side, not in the RAR or 7z libraries. The Archives plugin doesn't have all the very-long-path workarounds which are built into Opus itself, although this is more an oversight than anything intentional. I had not noticed it had issues with this before, and I think it is the first time it has been mentioned.
Since you have no control over the archives you receive from other people, it's something I think should work, so I'll see if I can port the workarounds in Opus over to the Archives plugin.
File explorer gives a different but related error. The MBT disk is fine but GPT disk expands one level deeper than before. Unlike DO which can actually navigate deeper on the right. File Explorer cannot. In File Explorer the folder displayed on the right when the tree is expanded three levels deep on the left does not update. When folder on the left is selected at the maximum depth where the bug manifests, that folder is itself and if selected on the right it does nothing other than repeatedly present and remove a checkbox for selection. If the folder on the right is on a drive where this bug does not manifest and a folder at the maximum displayable depth on the left is selected where the bug manifests, the folder on the right does not change and when selected on the right simply updates the tree on the left to reflect where the folder on the right is, when the folder on the right is double clicked in File Explorer.
I expect this is the same problem documented and unresolved here.
I don't actually believe that it is an MBR vs GPT issue, but rather some other minor quirk that the developer and tester didn't run into in their small test case.
I certainly expect this to be a Windows API problem. And who better to get them to fix it than their awesome third party developer DO. Grin. Seriously though, with the long path registry change\test implemented DO should be able to get a broader testing at Microsoft to get this fixed.
