Hi,
I have enabled the support for long path in my Windows OS as shown below.
The PDF file is also shown by Directory Opus when I navigate to the folder.
When I try to open the file by double clicking on it (Adobe Reader is the application in which it should open). I get following error.
Is this something to do with Opus or is it something else.
In spite of enabling long paths, why can the file not be opened ?
Thanks and Regards,
edou
Opus supports long paths even without the option turned on in Windows, and always has done.
That error is not coming from Opus - most likely it's coming from Adobe Reader itself.
Do you see the same thing if you double-click on the same file in Explorer?
Enable
@admin
reg add HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /t REG_QWORD /d 1
disable
@admin
reg Delete HKLM\SYSTEM\CurrentControlSet\Control\FileSystem /v LongPathsEnabled /f
I was thinking that if Windows 10 is enabled for handling long paths, all applications will work properly. However, what I found is
One of the largest paths I found was 305 characters (starting from E:\ and including .pdf).
Although Windows 10 allows long paths and it does show properly when I navigate to the folder in Directory Opus or even in File Explorer, it also depends on individual apps to use Windows 10 provided mechanisms to handle long paths.
Adobe Reader DOES NOT OPEN the file when I double click to open with Adobe Reader
Adobe Reader DOES NOT OPEN the file when I right click and try to open with Adobe Reader from context menu.
But a PDF Viewer called
PDF-XChange Viewer DOES OPEN the file perfectly fine by double clicking in Directory Opus.
PDF-XChange Viewer DOES NOT OPEN the file with right clicking on the file and using context menu to open with PDF-XChange Viewer.
I get following message (screen image attached)
Does right click and clicking on context menu get handled by Directory Opus or does Windows do it.
Some programs, parts of programs, and libraries, and even some Windows APIs, still used fixed-size buffers regardless of the Windows 10 setting. There isn't a way around it (unless you're the developer of those things).
The setting added in Windows 10 mainly removes limits within File Explorer (which were already removed in the most important parts of Opus), but can't remove them everywhere.
You should still try to avoid path lengths longer than 260 characters because they will cause problems with some software, as you've discovered.
You can sometimes work around the problem by passing the "short path" version of paths, but only if short paths are enabled on the drive in question. They aren't always enabled these days. (Turning them off improves performance, but removes the ability to use them as a workaround for software that doesn't understand long paths, unicode, spaces in filenames, etc. Microsoft seem to keep changing whether or not they are on by default in Windows.)
One reason not to turn on the Windows 10 long path option is that it makes it easier to make really long paths by accident. In Opus, we do things differently and try to ensure that you can work on paths which are already very long, e.g. to fix them and move/rename/remove things to shorter paths, but we don't make it easy to create things with very long paths, because they'll cause problems with so many other things.
I always try to avoid paths which are more than 255 characters long.
But in some specific cases they do inadvertently get created as e.g. when I backup a directory which has few files which are under the 260 character limit including path. When I back it up to some external drive and add root folders with date and/or machine name etc. the already long path names do get over the 260 character limit at that point of time. These are the files that cause the problem at a later date.
All said and done, finally I have to find all such files and take care of them individually to make it less than 260 or even better 240 characters.
Also I read that software which allow regular expressions to prefix path names, do allow to process the files when the \\?\ is used. However, I cannot figure out how to use \\?\ before the filename in path prefix. e.g. If I use E:\*.pdf with recursive to find all *.pdf files in E: , how do I use \\?\ instead of E:\. I am asking this as Directory Opus also allows regular expressions.
Thanks and Regards,
Behind the scenes, Opus adds the \\?\ prefix automatically for very long paths. But it won't usually do that when running external programs, as they may not understand it.
You can manually/explicitly add the prefix to the start of the current folder in the path field, and then do a Find from there, and then double-click the results. That may work, but it depends on the PDF viewer or whatever else you are running. A lot of things won't understand paths with that prefix.
Also note that paths are not always passed to programs, and especially context menus, as normal strings. Sometimes they're passed as special Windows Shell objects which may canonicalise the paths and remove any explicit \\?\ prefix.
How do I add the \\?\ manually as a prefix. Can you give an example with an actual drive name in use.
Say I want to change E:\<absolute very long path name> or just E:\*.pdf to use it with the
\\?\ prefix, what do I use ?
e.g. I want to find all PDF files on E drive irrespective of path length using above prefix manually and use double click to open the found files in even long paths, how do I do it ?
As I mentioned in my initial post, PDF-XChange Viewer PDF reader does open the file on double click (if I set PDF-XChange Viewer to be the default PDF app in Windows) when I navigate to the specific long path in question but Adobe Reader does not (when Adobe Reader is set as default PDF app).
But it does not help unless I can find all the PDFs in one go as it is not practical to manually find each path which is longer than 260 characters.
So I am interested in knowing how to use the prefix \\?\ with a real example as not all programs use \\?\ behind the scenes as Directory Opus does it.
Also note that Opus, as we keep saying, already supports long pathnames, and will search the whole drive including long paths whether you use this prefix or not.
