Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added support for tags stored on extended attributes (xattrs). #137

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fbarriga
Copy link

@fbarriga fbarriga commented Jul 1, 2018

This patch add support for tags stored on extended attributes (xattrs).
The changes are:

  • The tags are indexed and stored on the database
  • A new 'Tags' column is added

To test the feature you need a file system that supports xattrs (ext4/btrfs will work). In order to set the tags you can use caja file manager with caja-xattrs extension (https://github.com/mate-desktop/caja-xattrs), dolphin file manager or using command line:

$ setfattr --name=user.xdg.tags --value="foo,bar" file.txt

fsearch_tags

@cboxdoerfer
Copy link
Owner

Thx, that sounds like a great feature. Unfortunately it breaks the database format and the changes aren't backwards compatible with older database files.

In order to implement something like that properly we'd have to first rethink the database format, allowing it to be a little bit more flexible in regards to future additions.

@tomachinz
Copy link

I have a big pile of mp3s, some of which are higher grade "a-list" audio files, others are b grade. It would be mad real to be able to search ID tags in here and/or FS extended attributes alternatively (I could mass tag them all).

@tomachinz
Copy link

In order to implement something like that properly we'd have to first rethink the database format,

Perhaps easiest to wipe the db clean and rebuild with new schema? I would not mind the hit. Perhaps you mean it would need locks put in place and version checking. Thanks for making this great software by the way.

@Bonjour123
Copy link

Is this feature planned on the roadmap ?

@porridgewithraisins
Copy link
Contributor

@cboxdoerfer If I am not mistaken, we can now have this right?

file_block_size and folder_block_size being carried with the database means we can add the attributes to the database, right?

The PR is written to files that don't exist now, I don't mind refactoring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants