Tracker: add option to add file to blocklist

[nephele]

In the Add-ons section for files there should be an optin to "Add file to blocklist"

This should be available for files that are present on a packagefs mount, using this option should add the respective file to the packages file with a blocklist entry and remount the package (or tell packagefs in another way to change this view)

edit: another neat thing might be to have a "shadow" of the files visible only in tracker (that is perhaps no real inode entry presented in the posix api, but exposed to tracker with a specific call) And then have an option to unhide them

[pulkomandy]

"Add file to blocklist" is a quite confusing wording. Why not simply "Disable file"? Or why not even simply allow people to delete files from packagefs by adding them to the blocklist?

As you say, it also raises the question of how to undo this once the file is not visible anymore. Greyed out files with a special API seems a bit hacky and possibly confusing. Especially as there can be strange cases, such as multiple packages providing the same file. You block one, and then you can see the other. Do you still see a "greyed out" file with the same name alongside?

Also, why should that be "in the add-ons section"? That requires implementing it as a tracker add-on, in which case, well anyone can write an add-on that does this and it doesn't need to be part of Haiku by default. But I think you are aiming for a more integrated approach?

I think the most natural thing to do here would be to show blocked files in Trash? And maybe we can allow the "move to trash" to work? But it may not be so easy since the packagefs is considered read-only.

Maybe we also need to think of it in a more general way, and for example consider how we may integrate other advanced filesystem features (such as btrfs/zfs snapshots)?

[nephele]

Disable file would be fine, i thought of add-ons because other fs/file specific actions are there (like mark email as read)

Showing them in trash instead of grayed out/disabled is an interesting option too.

For the case of severall same files... hmm, I've not thought of such conflicts yet. Still, I think we do need this UI functionality.

[nephele]

For snapshots, as long as bfs does not support this (e.g bfs2 with an improved design, maybe) I don't think adding specific support to tracker makes sense.

[waddlesplash]

Having files show up in Trash which can't be deleted sounds very confusing. And honestly, the whole concept of adding a way to "blocklist" files to the UI sounds like a bad idea. Very few users will ever need this feature, and the ones that do should know what they're doing (or follow instructions carefully from someone who does.) That doesn't sound like something we want to have an easy shortcut to in the UI.

[nephele]

For system packages I would agree. For all others not so much. We already have UI in place that warns users of sensitive stuff in /system, we don't need to change anything here.

This should definetely be a gui feature, the whole "if you want to do advanced stuff edit a text config file" is an anti-pattern we shouldn't push in Haiku, only if it is truely neccesary. This shouldn't be the norm.

Hiding files is very usefull for pretty much any ported software that includes junk/ uneccesary files. or just easily testing if something is really required.

Instead of the trash can we could also have a second "can" with the hidden files or so, that would also be an option. Or having one folder in the trash can named "disabled files" with all of them in them.

[pulkomandy]

I think Waddlesplash is right that the proper fix for that is not to expose the block list in the UI, but instead to make sure the block list is not needed at all for normal users, only maybe when testing a driver. So that wouldn't even be "advanced use", that would be "I am a developer and I know how to recompile the system if I need to" level.

If you put all very advanced features in the UI, all you get is a very confusing "advanced" UI, and that's not really helpful.

Hiding files is very usefull for pretty much any ported software that includes junk/ uneccesary files

Why not fix the software packages to not include "junk" instead? I'm now curious if you have real examples of that, because it seems stretching the use of block lists further than I expected.

So, yes, there could be an UI for this, but I'm still not convinced that Tracker is the right place for it, or maybe not in the form you suggest. The fact that the block list makes files disappear from the filesystem is a problem in terms of UI. It would be nicer if the file was still here, but disabled. Maybe as a new special type of file. But I don't want this to be handled as special case in Tracker, if we go this way, it should be done at the filesystem level (think maybe something like a broken symlink, or a FIFO that exists on the filesystem yet isn't really a file).

That still does not solve the problem that there can be several packages providing the same file, and so, if you are looking at the merged filesystem, it will always be quite confusing if you handle it that way. I can also think of other ways to resolve this, for example, it could be shown as an extra tab in Tracker "Get Info" dialog alongside permissions and xattrs. There you could see a list of different file versions (in the case of packagefs: from different packages that provide the same file; in the case of zfs/btrfs: from snapshots), and select which one you want or maybe none at all.

It still leaves open the question that, once a file is deleted, if we completely hide it, there is no easy way to bring it back, making this UI asymetrical.

Having files show up in Trash which can't be deleted sounds very confusing.

It's what happens if you have files in the trash of any read-only filesystem. And packagefs is a read-only filesystem in pretty much all aspects. So that part isn't so confusing to me.

What would be strange with it having a readonly filesystem where you can still take files in and out of the trash.

Disable file would be fine, i thought of add-ons because other fs/file specific actions are there

That's not really the logic for it, add-ons is just extra functions provided by... add-ons. Some happen to work only on some filetypes, but not all of them. But in any case, it may not be a bad idea to implement this as an add-on to experiment with it and see if people pick up using it?

[nephele]

Why not fix the software packages to not include "junk" instead? I'm now curious if you have real examples of that, because it seems stretching the use of block lists further than I expected.

I'm not at my computer right now, but on the top of my head kded included systemd .service files, and another port added junk entries to the mime db. Severall others include .desktop files etc. As for the "why not fix the sw" part, the problem here is that it is a systemic problem (mainly because "easy ports" of "its just unix" software assumes a lot, and setting stuff like data dir or etc dir in a configure commandline automatically copies these junk files over if it doesn't know what haiku is.) and fixing it for all software I could download is too much work, and I wouldn't get anything else done in haiku. I do make sure no junk is included for stuff I ported however.

It would be nicer if the file was still here, but disabled. Maybe as a new special type of file. But I don't want this to be handled as special case in Tracker, if we go this way, it should be done at the filesystem level.

I think this is a great idea. Analogously FreeBSD has file system flags (​https://man.freebsd.org/cgi/man.cgi?query=chflags&sektion=2&format=html and ​https://man.freebsd.org/cgi/man.cgi?query=chflags&sektion=1) These serve a number of functions such as setting a file as hidden, immutable, append-only, undeletable, read only. Note that these aren't permissions as such but flags on the file. For example FreeBSD protects the kernel files with these to make sure they cannot be accidentally deleted.

We could adopt this model and add a flag for file disabled. (on FreeBSD ZFS also supports these flags iirc)

The idea of a tab for the different versions/views of a file is also great. I think this is a bit of a different issue to how one would disable files and show that, but it would be nice to implement too.

[pulkomandy]

As for the "why not fix the sw" part, the problem here is that it is a systemic problem

Systemic problems deserve systemic solutions. Having each user manually block the files isn't one. It doesn't save on disk space. It probably makes things slower overall.

One solution for this would be to add "strict" checks to Haikuporter that there is no "systemd" directory and no .desktop files, for example. Then, people will be forced to clean up their packages.