Use real path instead of url to retrieve file

I'm having the same issue with "drush cron". I applied the patch above as well the one I submitted in #1365148. Then I cleared the index and ran the "drush cron" command. I still get errors for files which are not parsed by Tika (images, plaintext).

So I extended the code a bit mor and added a new function which determines a file's realpath.

Seems to work except that German umlauts are removed by escapeshellarg(). If a file has something like "ä ö ü" in its name, then Tika throws an exception cause it cannot find a file after the umlauts have been removed...

Stream wrappers can register if they are remote or local using the type in hook_stream_wrappers(): http://api.drupal.org/api/drupal/modules--system--system.api.php/functio...

The function added in the patch should probably check the type of the of the scheme and if it's local, use realpath() and otherwise getExternalPath(). This allows to support both private:// (which currently doesn't work if anon users don't have access) and remote wrappers like s3://.

Another option is to set your $base_url in the appropriate settings.php file. That'll also fix URLs in various emails sent by the system on cron as well if you ever run into that.

Patch #4 works for me, however i'm agree with Berdir that it should be a bit smarter , i had a look at http://api.drupal.org/api/drupal/includes%21stream_wrappers.inc/7 but couldn't find anything that clearly indicated whether a wrapper is local or remote. If that's the case then a workaround should be used.
One solution can be check $wrapper class to see if it's a subclass of DrupalLocalStreamWrapper

 $local_wrappers = file_get_stream_wrappers(STREAM_WRAPPERS_LOCAL);
 if (isset($local_wrappers[$scheme])) {
 // then it's local 

(from image.gd.inc)

Attached is a new version of patch #4 based on the feedback by Berdir & mfb

Patch in #10 works for me, Thanks.

Haven't test patch #10 but the approach looks reasonable to me too.
@osopolar if it works fine for you , you could mark it as RTBC, i'm doing on behalf of you

I applied this patch and it seems to reduce the number of errors the drush command to index the site produces however I'm getting a lot of this..

INFO - unsupported/disabled operation: EI

What is that?

--Corey

Patch worked for me. However my case was a password protected site, so every time extract was getting a 401 error code.
Using the realpath solved the problem, because no URL is required anymore.

Also some "INFO - unsupported/disabled operation: EI" messages were shown, but the vast majority of the .pdfs were indexed properly.

Thank you for the patch :-)

patch works great. after hours of debugging why java was dumping with absolutely no reasonable explanation... sigh

This worked brilliantly for me. I had issues where I was using a self-signed SSL certificate (on my development) server which was causing Tika to error out.

assigning to me for testing and very probabely merging in the 7.x-1.x branch

Hi,
just merged it in 7.x-1.x branch
Thanks all !