Objective
My desire is to read and edit the metadata of files which have a path length longer than 260.
Problem Description
For a total path length less than 260:
I tried to edit the metadata of .jpe files that resided on a directory accessed using "\?" (e.g. "\?\C:\Temp\A.jpg"). I used Opus' metadata panel.
The result was not exactly what I expected. Pressing "apply" created a single new file (even if multiple were selected) with the name of the first file selected and the wrong extesion ".JPG2052" (e.g. "\?\C:\Temp\A.JPG2052").
By renaming that file to "A.jpg", I saw that the metadata was indeed applied.
For a longer path size (> 260):
Using "\?", Opus displays/reads the metadata of the file and does nothing when trying to apply new metadata.
Without the "\?", Opus does not displays the metadata.
I could not figure how to test this under "explorer.exe".
Requests
I would expect Opus to use "\?" under the hood automatically so it would display the metadata even when the directory for the files was not explicitly accessed using that way (and path.size > 260). Could this be implemented?
It would also be nice to be able to edit metadata in that case (path.size > 260). Could this be implemented?
We may be able to make this work, but in general can only guarantee that basic file management works in extremely long paths (~260 chars).
Basic file management as in: listing folders, copying, moving, renaming and deleting. (Deleting without the recycle bin. The Windows recycle bin does not work with very long paths.)
Almost all of the code we write ourselves can deal with unlimited path lengths, but parts of the Windows API itself cannot (e.g. the recyle bin), and the same is true for some library code which we depend on for some features. So it is hard to guarantee that everything will work.
It's still worth telling us when something doesn't work with huge paths as we may be able to fix it (e.g. by fixing some library code we use, or passing it short paths to increase the path limit).
But a very large number of other programs (and components like shell extensions and thumbnail extractors) will completely fail with very long paths. So it generally makes sense to reorganise huge paths, even when they don't cause problems in Opus. Opus can help you reorganise them as all the basics are made to work with them.