C-Command Software Forum

Index hanging on a file

When I start up EF, the activity viewer shows that the contents of my library are being indexed. The index stops on file 1039 of 1039 and doesn’t complete (I’ve left it for 10 minutes and it doesn’t complete). If I click the ‘x’ to cancel, the index cancels and I can continue to work OK. Is there an easy way I can find out which file is causing the issue?

Thanks

Do you see “efindextool” or “eftexttool” running in Activity Monitor?

If it was trying to read a particular file when you clicked the x, it will probably say so at the bottom of EagleFiler’s log file:

/Users/<username>/Library/Logs/EagleFiler/EagleFiler.log

Wow, quick reply :slight_smile:

Activity Viewer shows eftexttool (not responding)

The last entry in the log doesn’t look too helpful…

2007-03-27 19:27:31,080 - appcontroller.pyc:95 Launched EagleFiler 1.1.6 at 2007-03-27 19:27:31 -0700

OK. FYI, eftexttool is in charge of reading the contents of a file to extract the text that needs to be indexed. So if it’s hanging, it’s likely that we’d be able to identify the problem if we knew which file it was working on.

Sorry about that. I made some optimizations in the last version that accidentally made it no longer report which file it was indexing when you cancelled. I will send you a new build of EagleFiler that fixes this.

Update: index problem resolved itself
The problem I was having with the index hanging appears to have resolved itself. I’ve added a bunch more files to the library and now the index completes normally. Don’t know why, but I’m not complaining :slight_smile:

Me too

I’m actually having a similar problem. I let EF run overnight, and it still hadn’t advanced. It gets to something like entry 617 of 5900 and then stalls, efindex chugs away but it never seems to finish. I can’t quite tell what file it’s hung up on. The console seems to tell me when it adds files to the index, but it seems to report only after the fact (so it doesn’t get to the report of the one it’s hanging on).

What I’ve taken to doing is killing efindextool, which then allows EF to proceed (of course skipping the problematic file, and, it appears, not recording the results of a few indexings leading up to the problem file), but it hangs up again next time I open EF.

Some of these files are big image PDFs, with no text to index in them, and it is efindextool (not eftexttool) that seems to be active when it’s hung.

Anyway, if there’s a way to tell what file it’s working on, it would be quite helpful. Is there any way to discern this from the Queue.plist file in the temp directory, or from the message I get (jobs.pyc:639 indexing failed: <IndexRecordsJob 0x17ea6f30>) when I kill efindextool? (Or, could I maybe sign up to get the build that tells you when you hit cancel?)

Thanks!

If efindextool is hanging then the problem is not related to a particular file. eftexttool reads the files; efindextool adds the text to the index. Probably the index file is damaged. You could try closing the library deleting the YourLibrary.eflibrary/Indexes/Records.efindex file so that EagleFiler will build a new index.

Ah, ok. Good to know. And perhaps all of this killing of efindextool I’ve done contributed to the damage. It’ll probably take some time to rebuild the index, but this is good to know how to do. Maybe it could even be a menu option hidden somewhere, but deleting the index file is easy enough for now.

I’ll assume this will work, I’ll report back if there are any further problems. Thanks for the help!

I appear to have encountered the same problem, and have no desire to be introduced to efindextool, eftextool, or any other efintool (if you’ll pardon the expression) that doesn’t have an inviting and cheery graphical user interface in plain view in the program itself.

During the import of a directory that contains, in vast majority, several thousand text and PDF files, there were several large graphic files—including some Photoshop files—that I hadn’t realized were in several subdirectories, and that were taking a long time to import. I didn’t need them in the database, so I cancelled those imports as they were happening.

I don’t know if this has any bearing on the apparent hang-up of indexing I’m experiencing or not. I stopped the indexing and closed the program. When I saw this thread I was hopeful, but the discussion has left me at the starting gate. I’m posting this in hopes that something can be implemented so a problem in indexing will generate something more informative and interactive than an endless hang.

Could you be more specific? It’s hanging during indexing. What does it say in the Activity Viewer window? What happened when you pressed the x button to cancel?

If you quit EagleFiler and open the same library again, does the indexing complete, or does it hang again?

Sorry for the delay, but I’ve had connectivity issues.

What does it say in the Activity Viewer window?

When it hung during indexing, it had said “851 of 3,131,” with an estimated remaining time that I don’t recall. It was there for a very long time.

What happened when you pressed the x button to cancel?

As I recall, the indexing stopped, the Activity Viewer became blank, and after a little time a file structure appeared in the main files list pane. It was then that I closed the database and quit the program.

If you quit EagleFiler and open the same library again, does the indexing complete, or does it hang again?

I’ve just done that and it started re-indexing with the “Unfiled” folder highlighted. It’s gone through the files fairly rapidly, with a few taking longer than others. The Activity Window now says it’s “Indexing records” and says below the “fuel guage”: “3,131 of 3,131—About 5 seconds.” The “fuel guage” is still animated, but it’s been sitting there at “3,131 of 3,131—About 5 seconds” for quite a while now while I’ve been typing this response.

I have no idea how long I should wait to see if it’s going to come out of this. I’ll give it half an hour and come back and let you know if it does come out of it or continues to sit there saying “About 5 seconds.”

OK, before cancelling it, please open Activity Monitor and tell me if you see efindextool or eftexttool there. I appreciate that you don’t want to know about such details, but it currently is the best way for me to see what’s happening on your Mac.

Does the indexing stop if you click the x button in the Activity Viewer?

Hi. It wound up being much longer than half an hour because I was getting my connectivity issues fixed. It’s now a little over two hours later, and EagleFiler’s Activity Viewer is still showing exactly the same message as I posted before, with the “fuel guage” still grinding.

please open Activity Monitor and tell me if you see efindextool or eftexttool there

You just had to make me do it, din’t ya? :slight_smile:

Okay: with the same message still visible in EagleFiler’s Activity Viewer, when I open the system’s Activity Monitor and select “All Processes,” there is no efindextool or efextool—only Dock, loginwindow, and WindowServer.

Does the indexing stop if you click the x button in the Activity Viewer?

I just did that, the Activity Viewer said “Cancelling…” and now is blank. I’m leaving the database open.

Hope that helps.

That’s strange. Could you e-mail me the log file?

/Users/<username>/Library/Logs/EagleFiler/EagleFiler.log

Sent.

For the archives: it turns out that there were two problems. The first was a bug that could cause eftexttool to crash. This will be fixed in the next EagleFiler update. The second was a (presumably) damaged PDF file that Preview displays as truncated and Acrobat cannot even open.

EagleFiler 1.2 fixes the bug that caused eftexttool to crash when indexing certain files.