Dolphin won't show metadata for files in symlink path

I think this is related to this bug: https://bugs.kde.org/show_bug.cgi?id=333678

A partition mounted in /shares/share1 is indexed and dolphin shows file metadata in this folder - like a jpg image width and height, for example.

However, in ~/files/share1, where share1 is a soft link to /shares/share1, metadata is not shown.

Is there a way to fix this?

Thanks.

According to the bug report, no.

The metadata display in dolphin works fine here (also in such a case) with indexing disabled completely though.
Maybe just excluding the folder that contains the symlink (or maybe even just the symlink itself) might help too?

Oh, and you forgot to mention which openSUSE (or KDE) version you use. It’s KDE 14.12.3 (with Baloo 4.14.3) from the 13.2 update repo here.

It’s one of the folders I want to see the metadata, and it’s much more “reachable” via symlink. i.e., I want to search all symlinked folders at once.

Oops, shame on me :slight_smile:

OS: Linux 3.16.7-7-desktop x86_64
System: openSUSE 13.2 (x86_64)
KDE: 4.14.6

~> zypper se -iv baloo*

S | Nome            | Tipo   | Versão           | Arquitetura | Repositório                      
--+-----------------+--------+------------------+-------------+----------------------------------
i | baloo_kcm       | pacote | 0.1+20141112-2.3 | x86_64      | openSUSE BuildService - KDE:Extra
    name: baloo_kcm
i | baloo-core      | pacote | 4.14.3-4.2       | x86_64      | openSUSE-13.2-Update             
    name: baloo-core
i | baloo-file      | pacote | 4.14.3-4.2       | x86_64      | openSUSE-13.2-Update             
    name: baloo-file
i | baloo-kioslaves | pacote | 4.14.3-4.2       | x86_64      | openSUSE-13.2-Update             
    name: baloo-kioslaves
i | baloo-pim       | pacote | 4.14.3-4.2       | x86_64      | openSUSE-13.2-Update             
    name: baloo-pim
i | baloo-tools     | pacote | 4.14.3-4.2       | x86_64      | openSUSE-13.2-Update             
    name: baloo-tools
i | baloo-core      | pacote | 4.14.3-4.2       | x86_64      | (Pacotes do sistema)             
    name: baloo-core
i | baloo-file      | pacote | 4.14.3-4.2       | x86_64      | (Pacotes do sistema)             
    name: baloo-file
i | baloo-kioslaves | pacote | 4.14.3-4.2       | x86_64      | (Pacotes do sistema)             
    name: baloo-kioslaves
i | baloo-pim       | pacote | 4.14.3-4.2       | x86_64      | (Pacotes do sistema)             
    name: baloo-pim
i | baloo-tools     | pacote | 4.14.3-4.2       | x86_64      | (Pacotes do sistema)             
    name: baloo-tools
i | baloo_kcm       | pacote | 0.1+20141112-2.3 | x86_64      | (Pacotes do sistema)             
    name: baloo_kcm

Note: the two _kcm packages are the standard (exclude folders) and advanced (add specific folders) modules. They don’t seem to conflict, as changes made in one module appear on the other AFAICT.

You see the metadata even when indexing is disabled.

As indexing apparently doesn’t work with symlinked folders, I don’t really see another way.
And you already found a seemingly related bug report yourself.

Unfortunately, there will be any further Baloo update for KDE4, so this is unlikely to get fixed at all there anyway.

Oops, shame on me :slight_smile:

OS: Linux 3.16.7-7-desktop x86_64
System: openSUSE 13.2 (x86_64)
KDE: 4.14.6

~> zypper se -iv baloo*

Ok. As I said, it works fine with those packages here (i.e. dolphin does show metadata for the files in a symlinked folder), with indexing disabled completely.

Note: the two _kcm packages are the standard (exclude folders) and advanced (add specific folders) modules. They don’t seem to conflict, as changes made in one module appear on the other AFAICT.

Yes. They are just two different frontends to the same configuration files. (the official, limited one; and a third-party one, actually a port of the old Nepomuk config module, that offers all possibilities that baloo’s configuration allows)

Ah, great. Dolphin even show metadata for video files, which were not shown with indexing enabled, even on local folders.

Now, I see that content searching appear to only work on text-based files (including, for example, .mbox), but not on PDFs. For those, is there something that works with dolphin or should I go the recoll way?

Thank you for helping, wolfi.

Hm, metadata for video files should be shown for indexed files as well. After all the indexing uses the exact same program to get the metadata as the indexer does.

But, for indexed files, dolphin only shows the indexed metadata.
So maybe you didn’t have kfilemetadata-ffmpegextractor installed when they were indexed, or something like that?

Now, I see that content searching appear to only work on text-based files (including, for example, .mbox), but not on PDFs. For those, is there something that works with dolphin or should I go the recoll way?

You mean with or without indexing now?

If indexing is disabled, dolphin basically does a “grep” if you search by content I think.

I have no idea how/if Baloo’s indexing/search works with PDF contents.

But remember that there are different types of PDFs. Not all of them actually contain any text. Some have only graphics.

Regarding recoll, there’s a KIO slave as well, which you even can use in Dolphin/Konqueror:
http://software.opensuse.org/package/kio_recoll
I haven’t used it (I don’t even have recoll installed), but you’d probably have to enter something like recoll:/keyword as address to search for “keyword”.

Version 4.14.3-12.2 is installed, but only since yesterday after I read another of your posts and before I started this thread, so maybe there was no time for it to do it’s magic.

Without.

Most PDFs I have are work-related, text-based and non-DRM’d. It is those I’m (mildly) interested in content searching. Other files I only want to search by name.

AFAIR it integrates with krunner (ALT+F2), so you just have to type the search term in it and it will list, in krunner’s drop-down, the files with excerpts of the relevant content. It’s cool, actually, but can be a bit overwhelming when there are many hits.


Now something unexpected. I was thinking if, in baloo’s advanced settings, I’d just set the folder with the symlinks, and not the actual folders, and if I corrected this, the search might work. But on the settings which I had previously customized, the only folder set to search was my home folder, which does not contain the shares, only the symlinks to them. The excluded folders were listed correctly.

It seems that sometime between the initial advanced config and indexing, which took a couple of nights, and today, these advanced settings were lost. :/. No idea why.

If I re-add the folders (total: about 1 TB!) in the advanced kcm, will it trigger all the time-consuming indexing again? Or is there a way to check the database? The files total 41 MB:

:~/.local/share/baloo/file> ls -lhS
total 41M
-rw-r--r-- 1 blimmer users  20M Mar 20 22:09 position.DB
-rw-r--r-- 1 blimmer users  12M Mar 20 22:09 postlist.DB
-rw-r--r-- 1 blimmer users 4,7M Mar 20 22:09 termlist.DB
-rw-r--r-- 1 blimmer users 2,3M Mar 20 22:04 fileMap.sqlite3-wal
-rw-r--r-- 1 blimmer users 2,3M Mar 20 22:04 fileMap.sqlite3
-rw-r--r-- 1 blimmer users 760K Mar 20 22:09 record.DB
-rw-r--r-- 1 blimmer users  32K Mar 20 22:04 fileMap.sqlite3-shm
-rw-r--r-- 1 blimmer users  331 Mar 20 22:09 position.baseB
-rw-r--r-- 1 blimmer users  325 Mar 20 22:09 position.baseA
-rw-r--r-- 1 blimmer users  205 Mar 20 22:09 postlist.baseB
-rw-r--r-- 1 blimmer users  200 Mar 20 22:09 postlist.baseA
-rw-r--r-- 1 blimmer users   95 Mar 20 22:09 termlist.baseB
-rw-r--r-- 1 blimmer users   94 Mar 20 22:09 termlist.baseA
-rw-r--r-- 1 blimmer users   29 Mar 20 22:09 record.baseA
-rw-r--r-- 1 blimmer users   29 Mar 20 22:09 record.baseB
-rw-r--r-- 1 blimmer users   28 Mar 20 22:04 iamchert
-rw-r--r-- 1 blimmer users    0 Mar 20 22:09 flintlock

The thing is, that it won’t index your files again if they are already indexed.
So if they are already indexed, installing kfilemetadata-ffmpegextractor will not add the missing metadata to the index (I think).

You probably should force a re-index, by deleting the index (~/.local/share/baloo/file/), or turning indexing off and then on again.
To restrict the re-index to certain folders, I suppose it’s enough to exclude that folder, and then include it again.

Without.

Then Baloo’s search is not used. Dolphin just uses a plain “grep” in this case I think, as mentioned. It might even exclude non-text files from the search in that case, I don’t know.

Most PDFs I have are work-related, text-based and non-DRM’d. It is those I’m (mildly) interested in content searching.

Well, then you’d definitely should use some sort of indexing for them.
I don’t know whether Baloo fits your needs, but recoll should in any case. Though I never used both. I did enable Baloo’s indexing for some tests, but I never really used it or the search. Recoll I never even installed.
Personally I have no use for that and don’t want to “waste” my harddisk space with a big index…

Other files I only want to search by name.

That should be easily possible, with or without an index. You could even use locate/updatedb for that (there’s even a KIO slave for that… :wink: )

AFAIR it integrates with krunner (ALT+F2), so you just have to type the search term in it and it will list, in krunner’s drop-down, the files with excerpts of the relevant content. It’s cool, actually, but can be a bit overwhelming when there are many hits.

As I said, I don’t know it myself.
Apparently it does come with a KRunner plugin then?
You can use the KIO slave (recoll:/ or something) in KRunner as well though, like any other KIO slave.

It seems that sometime between the initial advanced config and indexing, which took a couple of nights, and today, these advanced settings were lost. :/. No idea why.

Well, I cannot tell you why either.
Maybe Baloo did notice that they are in fact the same folders? But then indexing/showing metadata information should work for the symlinks I suppose.

Just an additional remark to your initial problem:
If a file is in a folder that is to be indexed, but the file itself is not in the index yet, no metadata is shown, as Dolphin (or rather the metadata information panel/widget) wants to get the metadata from the index then.

Probably. Excluded files/folders should get removed from the index.

Or is there a way to check the database?

There definitely is, it’s a Xapian database, and the filemap is just SQLite as you can see from the file name.

And you can check whether a file is indexed with the command “balooshow”. “balooctl status” will show you how many files are indexed.

Thanks, wolfi. For now I’ll keep baloo inactive. I’d try more if it wasn’t going to be changed/substituted/killed/whatever in KDE5 as nepomuk was, as this will probably mean another round of buggy/not-quite-end-user-friendly-yet indexing.

From the little I learned recoll is excellent for work-related searches (i.e., mostly PDF and WP/text files), so I’ll probably install it again if/when I need it’s capabilities. For everything else, it’s no big deal the small time waiting for the results.

I’m very much a noob in relation to DBMS, so I’ll leave the SQLite thing alone. Too much to learn, too little time - story of my life :slight_smile:

No. Baloo is not going to be changed/substituted/killed/whatever in KDE5 at all.

It has been stripped down to be just a file indexer/searcher now, and only stores the indexed data in its database (e.g. the tags/ratings/comments are stored in the filesystem directly now via xattrs, not in Baloo’s database/index). But that already started with Baloo in KDE4 (that was actually the main purpose of replacing Nepomuk by Baloo).

And Baloo will probably get its own storage in the near future (at least they are working on that), because of licensing problems with Xapian which prevents Baloo from becoming a “Framework”.

You might read Vishesh Handa’s latest blog if you’re interested in the current status of “The Semantic Desktop”: http://vhanda.in/blog/2015/03/the-semantic-desktop-is-dead/

For everything else, it’s no big deal the small time waiting for the results.

Yes, that’s why I don’t use an indexer at all.
It’s just not worth it (I’m mainly concerned about the disk space of the index here though) for the few times I’d need it.

I’m very much a noob in relation to DBMS, so I’ll leave the SQLite thing alone. Too much to learn, too little time - story of my life :slight_smile:

Well, there are graphical frontends to SQLite as well, I think even LibreOffice Base supports it (not sure though)… :wink:
But that SQLite DB is actually only a map betweed internal id numbers and the filename/URL, to be able to access the indexed data via the file name and correlate the data to the actual file.
But just listing/browsing it should show you which files are indexed.