Using version 3.2.0.2 with PDF-XChange Viewer 2.5.212 (XCShInfo.dll) on Win 8/64
When I browse in a local folder and highlight an invalid PDF file so that its contents appear in the Draft Preview, and then Preview a different file or
browse a different folder, the QuickViewer holds the PDF open and/or locked so that it cannot be deleted, moved, or renamed.
After exiting and restarting XP2...
If I am careful to not-preview the PDF in Draft mode, it *can* be deleted, moved, or renamed.
Or, if I hide the QuickViewer and then highlight the bad PDF, it behaves as expected.
Or, if I preview the bad PDF in Native mode, it behaves as expected.
Testing Steps
10 Mode-Native PDF-Good Preview-Ok
20 Mode-Native PDF-Bad Preview-Ok
30 Mode-Draft PDF-Good Preview-Ok
40 Mode-Draft PDF-Bad Preview-Ok
-- At this point the bug is triggered
50 Mode-Draft PDF-Bad Delete-Fail "The selection does not support this verb"
60 Mode-Draft PDF-Good Rename-Success
70 Mode-Draft PDF-Bad Rename-Fail "The action cannot be completed because the file is open in xplorer2, Close the file and try again."
-- At this point un-do the bug by either closing and reopening xp2 or closing the file handle with NirSoft's OpenedFilesView
80 Mode-Native PDF-Bad Rename-Success
Windows Explorer has the opposite problem while a PDF is displayed in the preview pane:
it can rename the bad PDF but cannot rename the good PDF ("open in Preview Handler Surrogate Host").
There is a trick to selecting the PDF for Rename or Delete without previewing - right-click the file. This works in XP2 because right-click selects only, without previewing. This fails in WinExp because right-click selects *and* previews.
Screencaps are available but they wouldn't link here from tinypic.com because "It was not possible to determine the dimensions of the image."
Invalid PDFs locked by Draft QuickView
Moderators: fgagnon, nikos, Site Mods
Re: Invalid PDFs locked by Draft QuickView
If by "invalid" or "bad" you mean the PDF is encrypted or corrupted or cannot otherwise be opened, then it is Tracker Software's shell-extension itself which is failing when reading the object - with the direct side-effect of it locking the file.
As such, it is always the host process (in this case, x2) which gets blamed - but x2 cannot police the behaviour of 3rd-party shell extensions, nor easily recover from their failures and still maintain the integration level necessary for them to work in the first place.
As you can (at least similarly) recreate this same behaviour within Windows Explorer and its preview pane, so the issue is with PDF X-Change. I suspect though, that were you to raise the issue with them, they would probably recommend not attempting to preview or use such objects in any way, for fairly obvious reasons.
Also note that the X-Change "viewer" itself has been discontinued and superseded/replaced by the (also free) XChange Editor. You may (or may not) have more luck with the shell extensions in that version being better able to recover themselves, as at the very least it is still in development, unlike your current viewer.
Nikos tends to recommend Sumatra Viewer, though the preview-handler in that (which also works in x2) is rudimentary at best compared to XChange's functionality, but as such, it also may not crash as catastrophically. Note that it is possible to use the handler from one, but the viewer from another in this regard, if you can find a shell-handler which does not fail yet prefer to keep using XChange itself as your primary viewer.
As such, it is always the host process (in this case, x2) which gets blamed - but x2 cannot police the behaviour of 3rd-party shell extensions, nor easily recover from their failures and still maintain the integration level necessary for them to work in the first place.
As you can (at least similarly) recreate this same behaviour within Windows Explorer and its preview pane, so the issue is with PDF X-Change. I suspect though, that were you to raise the issue with them, they would probably recommend not attempting to preview or use such objects in any way, for fairly obvious reasons.
Also note that the X-Change "viewer" itself has been discontinued and superseded/replaced by the (also free) XChange Editor. You may (or may not) have more luck with the shell extensions in that version being better able to recover themselves, as at the very least it is still in development, unlike your current viewer.
Nikos tends to recommend Sumatra Viewer, though the preview-handler in that (which also works in x2) is rudimentary at best compared to XChange's functionality, but as such, it also may not crash as catastrophically. Note that it is possible to use the handler from one, but the viewer from another in this regard, if you can find a shell-handler which does not fail yet prefer to keep using XChange itself as your primary viewer.
Re: Invalid PDFs locked by Draft QuickView
i'm not sure what a "bad PDF" is, can you send me a small sample by email?
Re: Invalid PDFs locked by Draft QuickView
By "bad PDF" I mean any text file with a .PDF extension. Even though these files are named Filename.PDF, they do *not* have the '%PDF-1.2' file header. In particular, it's a two-byte file with two blank lines - two carriage returns (hex 0A 0A). Let me investigate further by debugging with Process Explorer and OpenedFilesView to clarify.
[Seex ow-ehrs lay-terrr...]
Browsing valid PDFs shows that Expoorer.EXE [sic] and xplorer2_64.EXE using Preview in Native mode both call C:\Windows\SysWOW64\prevhost.EXE. This Windows process holds the file open with Read, Shared-Read and Shared-Write permissions. When scrolling to later pages in the PDF, I can see the File Pointer
Position advance. While the file is held open, X2 can rename it but Windows Explorer cannot. Stop Press - here's a new gem: When the valid PDF is held open by either WinExp or XP2's Native mode, the relevant instance of PrevHost.EXE loads "...\Foxit PhantomPDF\Shell Extensions\FoxitPDFInfo.DLL". That makes sense because FoxIt is my PDF reader.
Switching now to text files mis-named as PDF but staying in Native mode, the file is not held open by anyone, so WinExp and XP2 both can rename it.
Now switching XP2's Preview to Draft mode on a valid PDF, the file is again not held open so the rename works fine.
Last switch - to a mis-named text file in Draft mode. XP2 *does* hold the file open, except this time the process name owning the file handle is xplorer2_64.exe and not PrevHost. Same permissions. The preview pane shows the file contents in hex. And the problem: XP2 cannot rename the file (WinExp cannot either) but strangely, Notepad++ *can* save changes to the file at the same time. Further, XP2 opens *another new file handle* every time the file is selected and displayed.
As background, I can see XP2 load the viewer module "...\PDF-XChange\Shell Extensions\XCShInfo.DLL" when browsing into a folder containing a .PDF extension. To be clear, the file handle is not opened until the file is previewed. As for WinExp, browsing into the test folder does *not* load a PrevHost.EXE or shell extension viewer. Only selecting a file named .PDF loads the FoxIt viewer module (valid PDF or not).
So yeah - if XP2 calls PDF-Exchange instead of the viewer that's registered in Windows (FoxIt), then the bug on invalid PDFs is likely in that viewer module's code, not in XP2.
The True Test: configure XP2 to use the FoxIt viewer, not PDF-XChange. I gather this is a system-wide Windows setting, and possible to change in the Registry, not in XP2. Even FoxIt's PhantomPDF reader has a "File Associations" dialog, with the option to "Restore a previously associated application as default PDF Viewer (if still installed): [Restore File Associations button]. But all this would do is revert back to PDF-Exchange, which we know has a bug. Or, install a newer module as Kilmatead suggests. Or, as he says in http://forum.zabkat.com/viewtopic.php?f=18 ... wer#p70326, would re-installing FoxIt really update which module is loaded by Draft mode? That post does not mention Draft vs Native.
Don't want to mess with the registry's GUIDs right now, so back-burnered the file-locking problem by turning off QuickView's Draft mode for PDFs using
x2SettingsEditor.EXE -> Layout Settings -> Default Layout -> General -> Draft preview types "-PDF". As expected, the bad PDF is not opened for QuickView.Draft so renaming works. Yes SearchFilterView can help figure this out.
So hang on, I know Draft mode is totally separate code from Native mode. From Kilmatead in http://forum.zabkat.com/viewtopic.php?f=18 ... iew#p63802, I understand that QuickView.Draft perform text extraction by loading iFilters, is that right?
So what's the difference in QuickView.Native, is that iFilters also? How does XP2 choose what viewer to load for Draft mode? How can I read and change that setting?
[Seex ow-ehrs lay-terrr...]
Browsing valid PDFs shows that Expoorer.EXE [sic] and xplorer2_64.EXE using Preview in Native mode both call C:\Windows\SysWOW64\prevhost.EXE. This Windows process holds the file open with Read, Shared-Read and Shared-Write permissions. When scrolling to later pages in the PDF, I can see the File Pointer
Position advance. While the file is held open, X2 can rename it but Windows Explorer cannot. Stop Press - here's a new gem: When the valid PDF is held open by either WinExp or XP2's Native mode, the relevant instance of PrevHost.EXE loads "...\Foxit PhantomPDF\Shell Extensions\FoxitPDFInfo.DLL". That makes sense because FoxIt is my PDF reader.
Switching now to text files mis-named as PDF but staying in Native mode, the file is not held open by anyone, so WinExp and XP2 both can rename it.
Now switching XP2's Preview to Draft mode on a valid PDF, the file is again not held open so the rename works fine.
Last switch - to a mis-named text file in Draft mode. XP2 *does* hold the file open, except this time the process name owning the file handle is xplorer2_64.exe and not PrevHost. Same permissions. The preview pane shows the file contents in hex. And the problem: XP2 cannot rename the file (WinExp cannot either) but strangely, Notepad++ *can* save changes to the file at the same time. Further, XP2 opens *another new file handle* every time the file is selected and displayed.
As background, I can see XP2 load the viewer module "...\PDF-XChange\Shell Extensions\XCShInfo.DLL" when browsing into a folder containing a .PDF extension. To be clear, the file handle is not opened until the file is previewed. As for WinExp, browsing into the test folder does *not* load a PrevHost.EXE or shell extension viewer. Only selecting a file named .PDF loads the FoxIt viewer module (valid PDF or not).
So yeah - if XP2 calls PDF-Exchange instead of the viewer that's registered in Windows (FoxIt), then the bug on invalid PDFs is likely in that viewer module's code, not in XP2.
The True Test: configure XP2 to use the FoxIt viewer, not PDF-XChange. I gather this is a system-wide Windows setting, and possible to change in the Registry, not in XP2. Even FoxIt's PhantomPDF reader has a "File Associations" dialog, with the option to "Restore a previously associated application as default PDF Viewer (if still installed): [Restore File Associations button]. But all this would do is revert back to PDF-Exchange, which we know has a bug. Or, install a newer module as Kilmatead suggests. Or, as he says in http://forum.zabkat.com/viewtopic.php?f=18 ... wer#p70326, would re-installing FoxIt really update which module is loaded by Draft mode? That post does not mention Draft vs Native.
Don't want to mess with the registry's GUIDs right now, so back-burnered the file-locking problem by turning off QuickView's Draft mode for PDFs using
x2SettingsEditor.EXE -> Layout Settings -> Default Layout -> General -> Draft preview types "-PDF". As expected, the bad PDF is not opened for QuickView.Draft so renaming works. Yes SearchFilterView can help figure this out.
So hang on, I know Draft mode is totally separate code from Native mode. From Kilmatead in http://forum.zabkat.com/viewtopic.php?f=18 ... iew#p63802, I understand that QuickView.Draft perform text extraction by loading iFilters, is that right?
So what's the difference in QuickView.Native, is that iFilters also? How does XP2 choose what viewer to load for Draft mode? How can I read and change that setting?
Re: Invalid PDFs locked by Draft QuickView
so how did you come about these "bad pdfs", is it something you just did to prove you are smarter than xplorer2? 
turning off draft quickviewer PDF is ok but if you try to search for text in PDFs then you will get the locking again
for more information about filter registration see last week's blogb
btw on my win10 with the default pdf text handler (that by windows), I see no locking with such "text" pdfs, so this is a problem with the PDF xchange shell extension. You can try the Sumatra one (just for its shell extensions)
and xplorer2 is very careful not locking files as you have discovered. If it detects you're trying to delete or anything else, it immediately releases the preview and anything else that would be locking. Of course it cannot help if some buggy shell extension keeps the file open
turning off draft quickviewer PDF is ok but if you try to search for text in PDFs then you will get the locking again
for more information about filter registration see last week's blogb
btw on my win10 with the default pdf text handler (that by windows), I see no locking with such "text" pdfs, so this is a problem with the PDF xchange shell extension. You can try the Sumatra one (just for its shell extensions)
and xplorer2 is very careful not locking files as you have discovered. If it detects you're trying to delete or anything else, it immediately releases the preview and anything else that would be locking. Of course it cannot help if some buggy shell extension keeps the file open
Re: Invalid PDFs locked by Draft QuickView
This trouble showed up again in 4.0.0.2 Ultimate. Draft preview was unexpectedly showing PDF content instead of blank. Deleting or renaming the invalid four-byte PDF was disallowed because the file was open in xp2. Close xp2 and re-open, then Draft shows the file is blank as expected, and file operations are allowed. Don't know what sequence of quick file operations kicks xp2 over into displaying PDF content in Draft mode even with preview types of "-PDF". It seems to properly ignore zero-byte PDFs.
BTW these are placeholder files. 12 are created at the beginning of the year, and one is populated at the end of each month.
BTW these are placeholder files. 12 are created at the beginning of the year, and one is populated at the end of each month.
Code: Select all
I:\>ChkShXt .PDF
Shell extension information for .PDF ...
1. TEXT FILTER -----------------
X64: C:\Apps\PDF\PDF-XChange ShlExt\XCShInfo.dll {1AC7939A-F487-4C8D-97AA-062FCA5DFA3C}
X32: C:\Apps\PDF\PDF-XChange ShlExt\Win32\XCShInfo.dll {1AC7939A-F487-4C8D-97AA-062FCA5DFA3C}
2. PROPERTY HANDLER ------------
X64: C:\Apps\PDF\PDF-XChange ShlExt\XCShInfo.dll {67EB453C-1BE1-48EC-AAF3-23B10277FCC1}
X32: C:\Apps\PDF\PDF-XChange ShlExt\Win32\XCShInfo.dll {67EB453C-1BE1-48EC-AAF3-23B10277FCC1}
3. PREVIEW HANDLER -------------
X64: C:\Apps\PDF\PDF-XChange ShlExt\XCShInfo.dll {CF822AB4-6DB5-4FDA-BC28-E61DF36D2583}
X32: C:\Apps\PDF\PDF-XChange ShlExt\Win32\XCShInfo.dll {CF822AB4-6DB5-4FDA-BC28-E61DF36D2583}
4. THUMBNAIL PROVIDER ----------
X64: C:\Apps\PDF\PDF-XChange ShlExt\XCShInfo.dll {EBD0B8F4-A9A0-41B7-9695-030CD264D9C8}
X32: C:\Apps\PDF\PDF-XChange ShlExt\Win32\XCShInfo.dll {EBD0B8F4-A9A0-41B7-9695-030CD264D9C8}Re: Invalid PDFs locked by Draft QuickView
sorry I have nothing to add, if you want to continue using invalid "PDF" files then you need to switch to another previewer (e.g. Sumatra PDF perhaps) that is more tolerant to them (?)
Re: Invalid PDFs locked by Draft QuickView
Outside Xplorer2, PDF-Xchange Editor (version 7.0) shows the same "seized file" behavior, sometimes.
After I open a PDF file, close it, and then try to delete it, sometimes I have to exit PDF-Xchange to unlock the file. It is intermittent.
(I just gave PDF-Xchange a non-PDF file. It rejected the file. But I could then delete the file. So today it works.)
After I open a PDF file, close it, and then try to delete it, sometimes I have to exit PDF-Xchange to unlock the file. It is intermittent.
(I just gave PDF-Xchange a non-PDF file. It rejected the file. But I could then delete the file. So today it works.)