Error searching some .doc files
A Windows File Searching Utility (grep)
Brought to you by:
jackslade,
theodoreward
This is a minor error, something I can certainly live with and not be bothered, but I figured you would want it reported. I'm using the latest (4.4.5) version of AstroGrep. When I search (plain search, with Search Subfolders checked), some .doc files generate an error: "Exception has been thrown by the target of an invocation." Other .doc files don't, and are searchable. I can't tell any difference in them. Anything I can do to help either fix the problem on my end, or provide the info you need to investigate on your end? (If we do nothing, I'm OK with that, too.)
(Previously posted accidentally in a discussion group.)
Anonymous
Thanks.
Here's one, along with its log file. (I narrowed my search down to just a few folders, one of which contained the problem .doc file.)
Note: While the search is underway, I see a status message that says, "Plugin Microsoft Word was used to search the file." I have MIcrosoft Word 2010 installed on this system.
Last edit: Mickey Ferguson 2016-09-27
In the log file it says: You are attempting to open a file type that is blocked by your File Block settings in the Trust Center.
I wonder if you have downloaded the file but haven't unblocked it. You can unblock it via Right click and Properties. At the bottom it should have an unblock checkbox.
Worth a shot at least. This probably happens with files downloaded from the internet.
If that is the cause, please respond back. I can then research if it is possible to bypass this check or not.
View and moderate all "bugs Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Bugs"
I see no place with an unblock checkbox. I'm running Windows 7 Enterprise. When I right-click and select Properties, everything looks normal to me, including on the Security tab, where I have full permissions for the file.
Mickey
From: Jackslade [mailto:jackslade@users.sf.net]
Sent: Tuesday, September 27, 2016 2:40 PM
To: [astrogrep:bugs]
Subject: [astrogrep:bugs] #93 Error searching some .doc files
In the log file it says: You are attempting to open a file type that is blocked by your File Block settings in the Trust Center.
I wonder if you have downloaded the file but haven't unblocked it. You can unblock it via Right click and Properties. At the bottom it should have an unblock checkbox.
Worth a shot at least. This probably happens with files downloaded from the internet.
If that is the cause, please respond back. I can then research if it is possible to bypass this check or not.
[bugs:#93] Error searching some .doc files
Status: open
Group: v4.4.5
Created: Tue Sep 13, 2016 10:18 PM UTC by Mickey Ferguson
Last Updated: Tue Sep 27, 2016 09:30 PM UTC
Owner: nobody
This is a minor error, something I can certainly live with and not be bothered, but I figured you would want it reported. I'm using the latest (4.4.5) version of AstroGrep. When I search (plain search, with Search Subfolders checked), some .doc files generate an error: "Exception has been thrown by the target of an invocation." Other .doc files don't, and are searchable. I can't tell any difference in them. Anything I can do to help either fix the problem on my end, or provide the info you need to investigate on your end? (If we do nothing, I'm OK with that, too.)
(Previously posted accidentally in a discussion group.)
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/astrogrep/bugs/93/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Related
Bugs:
#93OK, I figured out the problem. It looks like a default Winword setting for files to protect against potential malicious behavior. I just tried to open ReadMe.doc directly in Winword.exe, and it says Protected View: Editing this file type (Word 6.0 Binary Documents and Templates) is not allowed due to your policy settings. I went in and changed the settings, and now I no longer get these errors.
This appears to be a function of Word and nothing we can handle on our end directly. I'll leave this open for now to see about a better presentation of the error and/or display the solution.
Agree, and your proposal is perfectly acceptable. Thanks for investigating and ultimately helping me to find the solution on my own!
Closing, recommend using the new OpenXML word plugin that doesn't require launching the actual Word program to search.