Dolphin per directory settings revisited

Brainstorm
1

Would it be the end of the world to revisit how Dolphin manages per directory settings?

The problem is that in Dolphin to get per directory view, you have to enable it by settings that start littering dot files all over the filesystem. This is problematic as you don’t want to have these extra files everywhere. In some cases, it can be catastrophic if some app just reads all the files from a directory and now it tries to parse the extra dot file stealthily generated. (And please don’t make a comment about how an app should not do that, it’s a moot point.) Why can’t these settings be stored in a single file that exists in the user’s home?

It should work simply by taking the current path, checking the file if it has custom settings and if it does, then use those settings. If there is no path or it is ambiguous or whatever, then use defaults.

This should work in most cases where it matters without littering files all over. If the argument is that the path cannot be resolved reliably, then let me present the case of the location bar. It always has a working path to use. It even works over various KIO options that use custom prefixes and whatnot. If it has some edge case where it doesn’t work, that is better than it being a completely unusable feature due to littering problem. It’s always possible to just use default when not sure.

Also, this user-specific setting is actually better than a dot file. Because using the dot file in a shared location forces every user to follow the same settings. Each user likely has their own preferences. Not to mention if the location is not writable, the dotfile simply fails, but the suggested method would not.

What would be the reason not to do this?

2 Likes
2

One possible reason is that the setting would stay when the directory is moved. Whether that is desirable, though, is debatable.

1 Like
3

While I generally like your proposal and I think it merits serious consideration, I can imagine an edge case where it would be problematic.

Let’s say a user uses encrypted Vaults (such as the vaults functionality provided by KDE or an external program such as Veracrypt).

When loading an encrypted container in Veracrypt if the user selects his usual number handle to mount the container then all is fine. If they use a different number handle (for some reason) then the new path will not be able to match the path-specific folder view settings.

Having said that, I think that for the majority of KDE users it should be much more important to address the issue of separate users having their own unique folder view settings per folder.

OTOH even if we go with your proposal there’s a reason why we might want to provide the ability to retain the current system for users of encrypted containers:
To maintain the privacy of the contents of a mounted encrypted system. If you store the folder view settings on a “per-path” basis in a user accessible file (outside the encrypted container) then an evil-maid attack could get a hint of the potential contents of that hidden container based on the folder names.

Paranoid but plausible.

4

I don’t think the dotfile needs to be removed, it could still work as (maybe) override option and valid option to use. This would be more of new thing on top.

The privacy is good point. I guess something to ponder around that would be inclusive/exclusive rules of paths to ignore. And/or to encrypt the “database”. It might not be obvious that this could leak metadata so I don’t think it ever could be default option. But I think with warning it would be enough to inform about it for anyone who actually is concerned about that. After all many of the encryption methods do not protect against metadata leaks in the first place (in KDE Vault for example). You have to be rather advanced user to even consider that. (Something that might be useful to look into as well, but that’s irrelevant for this.)

Adding to that, some sort of rules would be extra feature on their own as you can set new default to be wider for all subdirectories. Say there is big collection of images with multiple subdirectories and you want to see all of them as big preview. But not apply the same setting for other directories.

The shared directory is more related to network mounts, such as SMB. And for example Windows doesn’t see dot files as hidden. If you work with git, you might suddenly notice how you pushed some extra dot files to the repo. I don’t think these are specially uncommon scenarios.

5

I was thinking that a potential way to ensure path/metadata privacy would be to calculate and store the SHA256 of the paths instead of the plaintext.

Pros:

  • Enhanced user privacy by default.

Cons:

  • Since the values are not stored as plaintext they are not easy to work with/modify. That can only be a problem for power users that want to manage their config files manually.
  • Since SHA256 is involved this could be slightly expensive in resources (CPU cycles).
6

Dolphin co-maintainer here.

This is reported as 322922 – Dolphin should not store .directory files inside the actual directory to avoid cluttering and polluting the filesystem; should instead store this data in extended attributes

Feel free to cc to the bug, this allows us to prioritize our focus, already about 11 users are CC.

  • it would quickly become outdated, each time you’d move a file it would loose the settings for the moved folder.

The other two are less relevant:

  • it could become big, slowing the filemanager down, and imply other impact when using files read and edited by multiple process.
  • it would be privacy-sensitivepotentially revealing all the path accessed in dolphin. We could be workaround easily though, store per-drive or mount, especially encrypted one, we already handle this for thumbnails.

The folder moving case.
We have no way to track a folder moving when doing file operation outside of dolphin, even as dolphin is running except for the currently displayed folders and keep the data associated with the folder.
You wouldn’t want to loose those settings just because you did a mv or use any other app to move folders.

Simpler design is most often superior, the current situation works great it is lightweight and mostly tech savy users are concerned with this.

So the current plan to solve this is to move the view settings from hidden folders to extended attributes, i.e file metadata. This is essentially the same simplicity except now only apps caring about this data will see it with no real downside.

I have began working on it. Progress is slow, on-hold currently, as I do other things, it requires a bunch of preliminary work to implement right.

To be precise I first need KConfig and KconfigXT to be able to save and read their data not only to/form a QFile but to/from a QIODevice, this requires some amount of refactoring and some tests.
Contribution welcome, I’d be happy to review this.

6 Likes
7

That’s interesting. I would have thought that trying to maintain compatibility with mv (or any other non-KDE program for that matter) would be considered out of scope from a KDE developer’s point of view. Good to know that this is a consideration.

I don’t want to discourage you from your approach but I think that trying to safeguard this level of compatibility is setting the bar too high because there are thousands of programs out there that could do a move folder action and ignore the xattr values. We wouldn’t be able to control all the scenarios and preserve the xattrs. What we can control is the KDE side of things.

The extended attributes solution sounds quite reasonable to me but I was wondering if there are any provisions on how to address filesystems that don’t support xattrs, such as NTFS.

Also will the xattrs solution support a “per user” value to determine the view preferences for each folder?

8

And even if your directories stay at rest on one machine you may be synchronizing them online between different machines or have different mount points using external storage.

You can argue if that desired but it is covered by the current implementation.

1 Like
9

And even if your directories stay at rest on one machine you may be synchronizing them online between different machines or have different mount points using external storage.

KDE version of .DS_STORE.

Also I think the “remember view settings in a directory not writable by me” argument is valid.

And there are transient directories like overlayfs, which the user might want to remember across sessions.

10

Essentially

Afaik non-writable and encrypted is currently stored in ~/.local/share/dolphin/view_properties/ which is kind of a global DB. Including the side effect of leaking information. There was bug report for it, but I can’t find it at the moment.

The whole topic feels like a “pick your poison” situation, which doesn’t have a solution but only tradeoffs.

11

Fallback to .directory file, we might consider the root hidden file solution, but I’d rather not. We might have a single view settings per mount or something like this to keep things simple, we already have such behavior in some case IIRC.

NTFS does support extended attributes in fact.

KDE does copy xattr by default indeed, mv and cp too on most common filesystems (ext4, btrfs, NTFS), rsync has a simple option, I expect any serious filemanager to already do the right thing, that would an easy bug to fix and easy to run into and to report.
But we can’t complain at the same time “some apps don’t work well with .directory files / I don’t like polluting hidden files” and “some apps don’t support xattr copying” opposing each other, the first case is much more serious and I am willing to make the compromise. Albeit for sure some obscure apps somewhere will hurt some users, or users will have to discover the -X option of rsync, and a few drawback, but making is making a few people unhappy hopefully not too-much and not too-many.
In any case view-props are not critical data.

Yes, we included this in our design.

Yes and by the new extended attribute proposed design as well.

As a side note, that would be the perfect way to consolidate custom-icon per-dir or color, or emblems or the .hidden file and easily sharing this with other part of the stack.
extended attributes are precisely made for this kind of feature.

And by the way, we already had a lot of discussion about this viewproperties.cpp: use url scheme and host for remote locations (!509) · Merge requests · System / Dolphin · GitLab exploring a lot of options.

Yes, indeed as always.

Any feature requires work, more code complexity, more CPU to run, to compile…
Any feature removed will need work and someone might be hurt in the process…
And any change includes a risk for regression…

The new design is a bit better, as for instance rsync does not copy extended attributes by default, and it is easy to strip extended attributes (as it is to remove .directory files).
It would be easy enough to special case, when copying to external or network fs with the current impl too.

That will be one of the fallback case, same as currently.
overlayfs is unlikely to be browsed with dolphin it seems to me. Compressed dirs or fuse mounts also could be concerned, but the situation does not change compared to now.

2 Likes
12

How about that!

I can vividly recall some years back when I tried to assign xattr tags to files/folder in an NTFS system that the values would not get stored.
Maybe I was doing something wrong. Or maybe this interoperability/functionality with NTFS was introduced to Dolphin at a later stage and I never noticed?

At any rate, today I learned and I am very happy about it! :smile:

13

It depends on the implementation to do it right.
In fact linux support NTFS xattr rests on its driver ntfs-3g did support it, and the new ntfs driver from linux 5.15 on seems to as well.
We will need to check.
On another, we know that we can have support for this change in Windows.

1 Like
14

This is one of the reasons why you should avoid using ntfs on linux, the drivers are closed source (proprietary of microsoft) so the linux drivers have been reverse engineered guessing how it should be done.

If you want to share a drive between windows and linux, use exFat instead, that driver is open source. No idea if it will support xattr or not though.

15

It seems your knowledge is outdated.

The paragon proprietary driver was open-sourced and upstreamed to linux 5.15 and supports reading and writing just fine, even compression, sparse files…

A filesystem is not something too hard to re-implement, since you can easily read the output of the reference implementation and it is generally at least partly documented. Not easy because it is big, but not completely as in the dark as say GPU drivers.

16

It’s not.
There is an open source nvidia driver, does that mean nvidia has shared the complete code for that driver and that that diver works exactly like the proprietary one? Ofc not.

This KERNEL DRIVER is the same. You have access to THAT code, but if that code is 100% after having been reverse engineered, nobody knows. Reading constant “why is my ntfs suddenly corrupt” over and over and over in forums tells me it is not a good practice.

And THAT is why I would NEVER recommend to use a filesystem where the driver is not completely “open source”.

Really?
If you use ntfs and mount that device every day for a month, it WILL get corrupted one way or another. The KERNEL DRIVER is better, but not perfect.

On linux, use linux filesystems OR at least a filesystem that has the original dirvers open source, like exFat.

17

This is problematic as you don’t want to have these extra files everywhere.

I don’t want to have these extra files everywhere? Interesting assumption. I don’t mind it. And it makes it clear where the settings for the folder lie.

In some cases, it can be catastrophic if some app just reads all the files from a directory and now it tries to parse the extra dot file stealthily generated.

Which app are we talking about? I haven’t seen that issue once in the 16 years I’ve been running Kubuntu and throwing tons of apps at it.

And “catastrophic”? You mean your hard drive fails from this? You can’t boot? That sounds like an exaggeration to me.

(And please don’t make a comment about how an app should not do that, it’s a moot point.)

But that begs the question, which app does something “catastrophic” from reading a dot file?

18

It’s an annoyance for software developers who navigate the filesystem with their terminals a lot, and have to manually remember to tell git to ignore those files. It’s also an annoyance for OCD people who have a habit of navigating their filesystems with hidden files turned on and twitch with rage over any file that’s automatically created without their express permission. :slight_smile: For normal people, it’s a non-issue.

2 Likes
19

It also annoys Windows users receiving tarballs from other systems. A search on “DS_STORE” shows that.

1 Like
21

personaly i never thought about doing this, but would this approach still be scriptable?

e.g. change PreviewsShown=false to PreviewsShown=true for a whole large set of directories,