File extension doesn't index symlinks when "inode/symlink" is chosen

[rsyring]

• Operating system: Xubuntu 16.04
• Desktop environment: XFCE
• Qt version: ??
• Albert version: 0.14.21
• How you installed Albert: PPA based in instructions at https://albertlauncher.github.io/docs/installing/#debian-9-ubuntu-1604-fedora-25-and-opensuse---obs-official

Steps to reproduce

1. Add a path to the file extension that has symlinks in it. All my symlinks point to directories, in case that matters.
2. In file extension, click "Advanced" and add "inode/symlink" to the box on the right, click save
3. Click "Start Scan"
4. Use albert to check for one of the symlink names

Expected behaviour

Find the symlink in albert's list.

Actual behaviour

Symlinks don't seem to be indexed, nothing comes up in albert's list

[ManuelSchneid3r]

There is no MIME type "inode/symlink". MIME type describes the type of data. Symlink is a file not data. From the Qt docs:

If fileInfo is a Unix symbolic link, the file that it refers to will be used instead.

You can choose to follow symlinks in the settings of the files extension.

[rsyring]

There is no MIME type "inode/symlink".

"inode/symlink" is listed in the MIME type filter just like "inode/directory" is:

You can choose to follow symlinks in the settings of the files extension.

I know that. I don't actually want to follow the symlinks (due in part to the fact that I can't limit how far the indexing descends into those directories). I simply want the symlink names themselves or the directories they point to (but not files/directories recursive).

[vspinu]

I second this, "follow symlinks" should not mean that symlinks themselves are dropped from the completion.

Plus that option is global to all paths which makes it inapplicable if I want symlinks from a handful of directories only.

[ManuelSchneid3r]

Plus that option is global to all paths which makes it inapplicable if I want symlinks from a handful of directories only.

there is an issue for that somewhere.

I second this, "follow symlinks" should not mean that symlinks themselves are dropped from the completion.

don't get this what do you mean by dropped from the completion?

[rsyring]

This is the other issue:

https://github.com/albertlauncher/albert/issues/143

I second this, "follow symlinks" should not mean that symlinks themselves are dropped from the completion.

don't get this what do you mean by dropped from the completion?

Albert's suggestions would be "the completion." He is saying that he wants to be able to index a symlink itself and not where a symlink points.

Can this issue get re-opened? I still think my original point is valid. There is a UI to include the symlink mime-type but it doesn't work. If indexing symlinks like this is not going to be supported then maybe the UI should be updated?

[ManuelSchneid3r]

inode/symlink somehow makes no sense to me because mimetypes describe the abstract concept of content type of data. Filesystem is a layer above and these mime types are abused to describe files not data. (actually inode/directory also makes no sense then, but thats another story). I see that the current state is inconsistent. Either inode/symlink should be handled or the inode/directory should be ignored. Since I'd like to not abuse things I think ignoring inode/* entirely is the best idea, because this way the mime type filter is what is meant to be: a data type filter.

[rsyring]

Well, FWIW, I would find it very helpful to be able to index directories and symlinks. In fact, that's almost the only thing I want to index because I find it easier to drop into directories than to lookup files. So, if you interested in my vote, I'd just rather have "inode/*" work as it would appear to work. If you want consistency in labeling, then maybe change the labeling to be "File Type Filters" instead of "Mime Type Filters" and then you can include "inode/*" as well as mime-types. Eventually, you might be able to add indexing by file extension.

[rsyring]

@ManuelSchneid3r Hate to be a pest, but I'd still very much like this feature. Being able to index a symlink means that I can index a folder full of "shortcuts" that I use frequently:

ls -lh ~/shortcuts/
total 4.0K
lrwxrwxrwx 1 rsyring rsyring 37 Nov  1 11:04 administrative -> ../dropbox/level12/tf-administrative/
lrwxrwxrwx 1 rsyring rsyring 27 Nov  1 10:55 applicants -> human-resources/Applicants/
lrwxrwxrwx 1 rsyring rsyring 26 Nov  9 12:12 bizdev -> level12-dropbox/tf-bizdev/
lrwxrwxrwx 1 rsyring rsyring 36 Nov  9 18:11 budgets -> level12-dropbox/tf-partners/Budgets/
lrwxrwxrwx 1 rsyring rsyring 27 Nov  1 10:54 contractors -> administrative/Contractors/
lrwxrwxrwx 1 rsyring rsyring 35 Nov  9 18:11 customers-admin -> level12-dropbox/tf-customers-admin/
lrwxrwxrwx 1 rsyring rsyring 33 Nov  9 18:11 customers-dev -> level12-dropbox/tf-customers-dev/
lrwxrwxrwx 1 rsyring rsyring 25 Nov  1 10:55 employees -> human-resources/Employees
lrwxrwxrwx 1 rsyring rsyring 25 Nov  1 10:54 financial-admin -> administrative/Financial/
lrwxrwxrwx 1 rsyring rsyring 26 Nov  9 18:11 hiring -> level12-dropbox/tf-hiring/
lrwxrwxrwx 1 rsyring rsyring 18 Nov  9 18:12 hiring-candidates -> hiring/candidates/
lrwxrwxrwx 1 rsyring rsyring 31 Nov  1 10:54 human-resources -> administrative/Human Resources/
lrwxrwxrwx 1 rsyring rsyring 18 Oct  4 13:50 level12-dropbox -> ../dropbox/level12
lrwxrwxrwx 1 rsyring rsyring 28 Nov  9 18:13 partners -> level12-dropbox/tf-partners/
lrwxrwxrwx 1 rsyring rsyring 20 Oct  4 13:50 personal-dropbox -> ../dropbox/personal/
lrwxrwxrwx 1 rsyring rsyring 36 Nov  9 18:13 prospects -> level12-dropbox/tf-bizdev/Prospects/
lrwxrwxrwx 1 rsyring rsyring  6 Oct 12 13:35 tmp -> ../tmp

I'd like to be able to index those symlinks, but not the contents of the directories that those symlinks point to.

[ManuelSchneid3r]

https://github.com/albertlauncher/plugins/commit/8b70313c73c7cda9f26928d98d06edd046945423 should have fixed this. Does v0.15 still have this problem?

[rsyring]

@ManuelSchneid3r no, symlinks are now indexed correctly Thanks!