Thumbnail is there for the mp4 and no longer crashes on opening. Solved 
1 Like
Thanks!
Thumbnail issue has indeed been fixed, but double clicking the files is still a no-op in DOpus (tried both pdf and mp4), while they launch just fine from Explorer.
Works fine here, using MPC-BE as the video player. Although it's working via short paths, so if those are turned off on the drive you're using it may be a problem.
There's no way to guarantee that all programs you're telling to launch a file, and all methods of doing so, are going to support paths longer than 255 characters. You should really consider shortening the path lengths, or you're just going to get a fix for one thing and then find another is broken again and again. Windows, and most Windows software, simply doesn't cope with paths that long very well.
As a note, the issues we fixed in the last beta were limitations of the Windows shell APIs, not with Opus itself. We worked around them, but the issue was Windows, which still has a lot of APIs that have path length limits. (Explorer itself is presumably using different APIs, but that's pure chance.)
At some point you will also run into the Windows command line length limit, which is 8191 characters (including the path to the program being run, any file paths passed to it, and any extra arguments). That's a hard limit you won't be able to work around.
1 Like
Works fine here, using MPC-BE as the video player. Although it's working via short paths, so if those are turned off on the drive you're using it may be a problem.
Hmm, it doesn't work for PDFs (PDF-XChange editor) or videos (mpv) for me.
I understand that there may be some apps that will not support long paths, and I wouldn't be complaining here if it was the issue. But this is clearly not one of those cases as Explorer somehow manages to launch these files.
This is a network drive shared by Windows and Linux devices, so it doesn't make sense to try to make all paths shorter than the 255 MAX_PATH value.
As a note, the issues we fixed in the last beta were limitations of the Windows shell APIs, not with Opus itself. We worked around them, but the issue was Windows, which still has a lot of APIs that have path length limits. (Explorer itself is presumably using different APIs, but that's pure chance.)
Look, I'm looking at it strictly from a user's point of view. I have something that works in Explorer (a free product) and doesn't work in DOpus (a paid product). I just want basic parity with Explorer.
At some point you will also run into the Windows command line length limit, which is 8191 characters (including the path to the program being run, any file paths passed to it, and any extra arguments). That's a hard limit you won't be able to work around.
~8K is a lot, and PowerShell's limit is around 32K, and on many Linux distros it is much higher. But you let me worry about that :).
Would you be able to make a ProcMon log while trying to open those files in both Opus and Explorer?
While I was trying to collect ProcMon logs I ended up discovering a few more things.
When using Explorer, if the network path becomes longer than 260, it prepends "\?\UNC" to it, e.g. "\\qnap\media\DOpusTest\... -> \\?\UNC\qnap\media\DOpusTest\....
These files have thumbs but they do not launch in Explorer either!
On the other hand, if the folder path (aka dirname) is less than 260, and the filename will push it over the limit, the files launch just fine in Explorer but not in DOpus.
Example:
\\qnap\media\DOpusTest\Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long\5Second_Level_Second_Level_Second_Level_Level_Second_\asdasddasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf.mp4
Here the full path is >300 chars but since the dirname is less, Explorer doesn't prepend \\?\UNC to the path in its location navbar and it is able to launch the target process.
The mpv player ends up having this cmdline (got this from ProcMon):
"C:\Utils\mpv\mpv.exe" -- "\\?\UNC\qnap\media\DOpusTest\Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long_Path_Long\5Second_Level_Second_Level_Second_Level_Level_Second_\asdasddasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdf.mp4
I tried to launch the cmd manually from the cmd prompt and it worked as well.
I tried to modify the cmd line and to use a path where the dirname was longer than 260 and launching it manually, and mpv actually run just fine with it!
Looking at ProcMon outputs of when it works and when it doesn't, it seems that in the cases where Explorer doesn't open the long path there's not a ProcessCreate in the log -- so it's not like the target process (mpv/pdf viewer) starts with an error and exits immediately... for some reason it just doesn't launch it.
This whole crappy behavior makes me want to go back to Linux, heh. I don't understand why:
- Short dirname, but long full path is OK for Explorer
- In the case of long dirname as well, why thumbs are generated but double-clicking doesn't seem to even launch the target process.
The \\?\UNC prefix is a standard thing in Windows, and used to disable path length limits.
It sounds like mpv.exe doesn't like the prefix, which is a problem with mpv.exe. Especially when Explorer also adds the same prefix in some situations.
Sounds like Explorer also has a bug where it doesn't properly switch into long path mode based on the full path, only the parent path.
There's not really any logical basis for Explorer's behavior - the path length limit is on the whole pathname, not just the path without the filename appended. The fact that it doesn't add the \\?\ prefix even though the full pathname is > 260 seems like a bug to me.
I think it's just luck that the files you've been testing fall into this category. MPV obviously can't handle the \\?\ prefix, but due to Explorer's weird behaviour it ends up passing an unprefixed (but overlong) path into MPV - which presumably MPV itself handles in some way that doesn't end up exceeding the path length (e.g. maybe MPV does a CD to the parent folder and then opens the file using just the filename, or something like that).
2 Likes
I think you misunderstood me, mpv doesn't have any issues with the \\?\UNC prefix paths. As I mentioned in my post above these paths work just fine if I run the command from the command line. The only issue here is Explorer not launching anything when the dirname is longer than the limit, but working just fine when dirname is under the limit even if the full path is over the limit.
I guess these are all just hueristics to protect against launched programs not being able to support long paths?
Is it possible to just have a flag in DOpus to tell it to ignore any such limit checks and just launch processes with the full UNC path (if the path exceeds the limit)? If this mode is enabled, it would be my responsibility to handle programs that don't support long paths properly.
In my case both my PDF editor and mpv seem to support these long paths without a problem as evidenced by the fact that launching from the command line works without an issue.
I guess first we have to see if you guys can actually reproduce the issue of not being able to launch these kind of files via double click in DOpus. Also, I'd be happy to send any relevant DOpus logs.
What does ProcMon show as the command line in a case where it doesn't work?
I said in my post above that there is no ProcessStart event when it doesn't work. It simply doesn't even start the process so you can't see the command line.
Ah, sorry; I missed that among the other details.
However, I've debugged what happens and there's nothing we can do here. ShellExecuteEx simply doesn't work on paths longer than ~260 characters. There is no workaround, other than using the "8.3" short path instead, which we already do if it's available. (Either 8.3 short paths are disabled on the drive you're using, or the path is so long that it's still too long even then.)
There's some discussion of it here if you don't believe me: winapi - Windows ShellExecuteW with filename that exceeds MAX_PATH (260 characters) - Stack Overflow
As I said, large parts of the Windows API still don't support long paths. Many can be made to do so via the \\?\ prefix, but that doesn't work with ShellExecuteEx, which is the primary method of launching programs in the Windows shell API.
Perhaps File Explorer launches things in a different way in some situations, although I'm actually surprised it's not using ShellExecuteEx here as well.
At the end of the day, you will need to rename your paths to something shorter, or enable short paths on the drive they are on. Even if this particular problem wasn't there, you'd soon run into another one.
As an aside, many tools won't work on long paths even if they're run with them via other methods. Excel is an example, and suffers from the problem in both Opus and File Explorer.
2 Likes
Thank you very much for looking deeper into this.
You're right that I have disabled the 8.3 file format for this drive via the QNAP options:
I did that a long time ago because otherwise it ended up showing me certain files which had forbidden characters (e.g. :) using mangled 8.3 names. Of course these files cannot be handled by Windows, but at least I knew what they were and could manually change them via Linux if I needed to (see Correct mangle filename for all shared folders in one time.(8.3 Filename) | QNAP).
I guess I will give up on this. But here's a naive question -- why not use lower level APIs that do support long paths? (of course, with the risk that the app itself may not support them, but at least it would launch and fail, rather than silently failing)
For example, see: xplorer² blog: to MAX_PATH and beyond (programmer's deep path cookbook)
ShellExecute doesn't deal with \?\ prefix either. What's the point storing a document somewhere when you cannot even open it? The way out of this ravine is to use AssocQueryString to manually locate the program that will open a file type, then launch it with CreateProcess. The latter can pass command line arguments that are situated deep. Still many programs like Notepad or all MS Office suite will just fail. Irfanview works but it is a small consolation
Because they don’t do the same thiing.
Why are you using such long file paths?
Copy and paste one of your long file paths.