Generic attributes app

Experimenting attributes :

  • Audio files located on BFS here (but in real life, it will be on my NAS, so no BFS)
  • Audio link : derived from audio mime type (ie containing some audio attributes extracted from the exif of the original audio) + new attribute corresponding to the link to the original file
  • Opening attributes via Attrify application : audio mime type attributes + audio link mime type attribute (link only)
    => Once the audio links files are enriched with exif data, the search for attributes can be done with query under Haiku

We can see that “audio-link” inherits from audio (in the tracker and in the filetypes) :

4 Likes

you can definitely have (extended) attributes on most of the common filesystems available on Linux as well as Mac’s HFS Plus. Decompressing with a tool that handles them just might require some work… I don’t remember how I transferred some of my files with attributes intact from Haiku to ZFS a year or two ago but I’m pretty sure it’s possible with some existing tools.

The attributes on other filesystems are not typed, and,more importantly, not indexed. That makes them a lot less useful, since queries will be very slow

1 Like

While it’s of course true they are much more prominent on BeOS/Haiku, my main point was that it does not need to be the case that you lose all attributes when going to a non-BFS filesystem.

In some cases using certain tools they can even be indexed although in userspace instead of at the filesystem level. Limited queries can also be practical with how fast disks can be nowadays even when not using an index (and Haiku’s indexing unfortunately leaves a lot to be desired because BeOS’s did) but I do think extended attributes are sadly underused on systems other than Haiku nowadays.

Maybe call it Object app :wink:

Yes, the attributes are only intended for the Haiku filesystem (bfs) and can only be used there. As soon as you copy the file to another filesystem, the attributes are gone. However, you can simply compress and extract the file with the zip command without losing them. Copying from bfs to bfs is no problem.

However, it’s important to remember that every attribute has a size, which isn’t displayed in the system (or has that changed now?). So if a new application writes new attributes to every file/program, that wouldn’t be nice in my opinion, and if I were building an anti-spyware app, I’d pay close attention to something like that ;-).

There’s also an app you can use to edit attributes. It’s called QuickRes.
I only know the 32-bit version.

Introducing QuickRes
QuickRes: So You Have a Bunch of Resources – Now What Do You Do?

quickres is an old beos application by Dianne Hackborn

I always used this to check when creating my genealogy program myfamily (unfortunately never completed due to missing options in yab and better alternatives)

I wish we had QuickRes for 64bit Haiku.

2 Likes

I don’t know about copy utilities but I believe you should be able to mostly transfer them to other filesystems by enabling xattr support in GNU tar / BSD tar.

Maybe Diane still has the source code and is willing to share it? She’s on Mastodon I believe.

1 Like

Work in progress : “open link” feature.

When a “Media:link” attribute exists on the file, an open button is displayed in order to launch an “open” command on the link.

This is working fine on audio file as per below (located on a NAS versus the “audio-link” file located on the Haiku system):

3 Likes

Proof of concept : how to search an audio file not located on a BFS volumes (ie on a non-BFS NAS).

The constraint is to create some “link” attributes files for each original audio files

1 Like

Wow.. thanks four your info, i’m never expect that link can have attributes too

It’s not really links, it’s a specific data type which contains a « link » in its attribute.

Symlinks can indeed have attributes as well. You can do that with the -P option for addattr. I use it in ACE to run the emulator with different configurations that are read from the symlink’s attributes

2 Likes

Oh I wasn’t aware of that, I will check :slight_smile:

If I understand correctly, a symlink can have additional attributes, however if I made a symlink of an audio file or a sound file, it will not inherit the attributes from these files ?

Would it be possible to create a new filetype’s group named “symlink” as below and define sub filetypes link audio, image, etc ?

The idea would be to have symlinks with attributes depending on the type of the original file

I’m experimenting symlink with attributes.

The below script is creating a symlink of an audio file located on my NAS.

When trying to open/play the audio file I have the below error:

However when opening the original audio file, it’s OK ie the track is opened with Media Player:

When the original audio file is located on the same BFS partition, the symlink is correctly opening the audio :

Any idea on what is wrong with the first symlink ?

1 Like

Maybe patch the below FSUtil.cpp file in the Tracker in order to handle file sniffing for non-BFS volumes ?

static bool
SniffIfGeneric(const entry_ref* ref)
{
	BNode node(ref);
	char type[B_MIME_TYPE_LENGTH];
	BNodeInfo info(&node);
	if (info.GetType(type) == B_OK
		&& strcasecmp(type, B_FILE_MIME_TYPE) != 0) {
		// already has a type and it's not octet stream
		return false;
	}

	BPath path(ref);
	if (path.Path()) {
		// force a mimeset
		node.RemoveAttr(kAttrMIMEType);
		update_mime_info(path.Path(), 0, 1, 1);
	}

	return true;
}
1 Like

Usage of symlink with audio:

  • Symlink is on BFS volume + audio attributes attached to it
  • Original audio file is on non BFS :slight_smile:

It should allow to make nice queries in Haiku relative to this “external” audio file

4 Likes