Skip to content

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

Open
fbarriga wants to merge 1 commit intocboxdoerfer:masterfrom
fbarriga:fbarriga/xattr_tags
Open

Added support for tags stored on extended attributes (xattrs).#137
fbarriga wants to merge 1 commit intocboxdoerfer:masterfrom
fbarriga:fbarriga/xattr_tags

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.

@Kreijstal
Copy link

@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.

interested in the 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.

6 participants