Comment 25 for bug 517021

Revision history for this message
Ben Bucksch (benbucksch) wrote :

Because some people here apparently treat silence as "I guess this is fixed", I'll spam here and say this keeps happening for me regularly as well. I've tried various things, killing the process, killing the directory IIRC, but it keeps coming back with 100%, maybe once a week or so, but it's irregular.

1.
I've probably seen 100 posts on the Internet saying to delete the metadata folder, but that's not a solution:
Even if it does get corrupted, the program MUST NOT go crazy and into an infinite loop or hog the CPU.
That said, I do NOT think that metadata file corruption is the problem, because the problem keeps coming back for me.

2.
I have huge NFS drives with many files mounted. If it tries to index or capture them, then it's sure to cause problems. People above said that it tries to index Samba drives. That's massively misguided and should not happen. It should only index local drives. Network drives can be huge, and often contain data that's not important to this user, but to other employees. In my case, it's media files (TV recordings, music etc.), but still *way* too huge to be indexed on the client. Even attempting to do this is braindead (this is technical term, not an insult).

3.
Last, but most importantly, no program has the right to index all my drives without my *explicit* permission. Ask me, once. Give me a choice of which drives I want indexed, and where that index should be stored.
This can be dangerous. People regularly keep private stuff on a physical USB drive, for the explicit reason to not leave trails on the local computer - whatever reason they might have. Having metadata about files stored on a *different* drive (partition) is a privacy threat by its very nature and should never be done without explicit user approval.

This stuff is totally misguided and should be disabled RIGHT NOW, then fixed, then it can be enabled again.