Bug 488626 - Please make Dolphin hide 'lost+found' dirs by default, just like Thunar does
Summary: Please make Dolphin hide 'lost+found' dirs by default, just like Thunar does
Status: RESOLVED WORKSFORME
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 24.05.1
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-17 16:54 UTC by Eduard
Modified: 2024-07-13 09:53 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eduard 2024-06-17 16:54:26 UTC
SUMMARY
It would be great if Dolphin showed the same behaviour as Thunar, with that it hides 'lost+found' directories just like dotfolders.
These folders are generated by fsck on Linux, and they are inaccessible for non root users. Hiding these folders is great thing.
With the Ctrl+h you can switch between showing/hiding these folders.

STEPS TO REPRODUCE
1. Open Dolphin.
2. Navigate to a root folder of some mounted partition.
3. You can see that Ctrl+h does not make the directory visible/invisible.

OBSERVED RESULT
See description.

EXPECTED RESULT
See description.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1

ADDITIONAL INFORMATION
Comment 1 Felix Ernst 2024-06-20 15:56:42 UTC
>These folders are generated by fsck on Linux, and they are inaccessible
>for non root users. Hiding these folders is great thing.

Would you please clarify why you think lost+found directories should be hidden? Your reasoning makes it sound like you want every folder that is only accessible for the root user to be hidden.
Comment 2 Eduard 2024-06-20 23:45:22 UTC
(In reply to Felix Ernst from comment #1)
> >These folders are generated by fsck on Linux, and they are inaccessible
> >for non root users. Hiding these folders is great thing.
> 
> Would you please clarify why you think lost+found directories should be
> hidden? Your reasoning makes it sound like you want every folder that is
> only accessible for the root user to be hidden.

Hmm, I see your point. Which is about looking for a logical and consistent reason to do things.
And a good question here is whether I explained my thoughts well enough.

Actually I believe what drove me to this question the most is that this folder is so standard on file systems that it's basically always there.
And the idea of consistency between how different file managers on Linux should handle things. So when one file manager hides it. It could be great if others do the same thing.

Probably one reason I  notice it so much is because I have multiple drives and partitions mounted in my system, and all Ext4 or Btrfs files systems do have this folder.

But NTFS file systems which I share with Windows have folders like "$RECYCLE.BIN" and "System Volume Information".
Which could already be a reason to think about more situations to filter things. But Thunar does not filter these away as these have nothing to do with Linux basically.

Are there defined standards beyond dot files and dot folders which describe these as that they should be hidden?

Otherwise maybe some custom and user configurable filter list could also do the job?
Comment 3 Felix Ernst 2024-06-21 13:12:06 UTC
>Are there defined standards beyond dot files and dot folders
>which describe these as that they should be hidden?

Actually as far as I know even the standard of dot files being hidden is mostly "a standard" because everyone does this. Dolphin could simply show dot files like normal files and we wouldn't break any compatibility or any official standard. We would only break user expectations. (https://unix.stackexchange.com/questions/88875/why-are-filenames-that-start-with-a-dot-hidden-can-i-hide-files-without-using-a)

So no, there is no agreed on convention that lost+found directories should be displayed as anything other than a normal folder as far as I am aware.

>Otherwise maybe some custom and user configurable filter list could also do the job?

Indeed we have something like this already! See: https://superuser.com/questions/826194/how-to-tell-dolphin-which-files-to-hide

Basically you would need to create a text file called ".hidden" next to the "lost+found" folder and then write "lost+found" into the ".hidden" file. Dolphin will read the contents of the ".hidden" file and make sure the "lost+found" folder will be treated like it was hidden.

Does that work for you?
Comment 4 Eduard 2024-06-23 09:55:04 UTC
(In reply to Felix Ernst from comment #3)
> >Are there defined standards beyond dot files and dot folders
> >which describe these as that they should be hidden?
> 
> Actually as far as I know even the standard of dot files being hidden is
> mostly "a standard" because everyone does this. Dolphin could simply show
> dot files like normal files and we wouldn't break any compatibility or any
> official standard. We would only break user expectations.
> (https://unix.stackexchange.com/questions/88875/why-are-filenames-that-start-
> with-a-dot-hidden-can-i-hide-files-without-using-a)
> 
> So no, there is no agreed on convention that lost+found directories should
> be displayed as anything other than a normal folder as far as I am aware.
> 
> >Otherwise maybe some custom and user configurable filter list could also do the job?
> 
> Indeed we have something like this already! See:
> https://superuser.com/questions/826194/how-to-tell-dolphin-which-files-to-
> hide
> 
> Basically you would need to create a text file called ".hidden" next to the
> "lost+found" folder and then write "lost+found" into the ".hidden" file.
> Dolphin will read the contents of the ".hidden" file and make sure the
> "lost+found" folder will be treated like it was hidden.
> 
> Does that work for you?

Thanks for the detailed reply! So it's an actual story of a bug that became a feature. Cool and I didn't know that. :)

Yep the .hidden file works! Although it looks like it had some delay before it showed up, but that's not a huge issue.
I also notice it works with Thunar as well (which I still use as well next to Dolphin, as both have there strengths), so this completely makes things work the same way. Thunar still displayed the NTFS "$RECYCLE.BIN" and "System Volume Information" folders, which I liked to hide as well. Now that's solved too with .hidden.

However, that gives a lot of specific control per directory, but it wouldn't be great if Dolphin had a general configuration option for this too? But lower priority wish, I get it.
And then I am going to have that same wish for Thunar as well. :P
Comment 5 Felix Ernst 2024-06-24 13:18:02 UTC
(In reply to Eduard from comment #4)
>Thanks for the detailed reply!

You are welcome!

>Now that's solved too with .hidden.

I am glad to hear that!

> However, that gives a lot of specific control per directory, but it wouldn't
> be great if Dolphin had a general configuration option for this too? But
> lower priority wish, I get it.

It's a bit too niche I think. Creating such a .hidden file is quite easy and one only has to do it once per file system. As a general option for hiding we have already recently added a setting in Dolphin's settings dialog to hide application/x-trash mime types. Users can already modify that any file extension belongs to that mime type and hide them this way. And I don't want to be too eager to hide that folder either because it can be very important for recovering data. Actually, it might make more sense to bother the developers of the fsck utility to not create such folders in the first place. That's on them after all (https://www.baeldung.com/linux/lost-found-directory) and conceptually it seems easier to me to not create a random empty folder when it isn't needed rather than have every application that shows folders to hide it.

Dolphin provides various ways of hiding already and we do inform about them in the extended help text of the Dolphin hiding feature. I think we should have most workflows covered this way. There are unfortuantely sometimes aspects which are so custom and specific to users that adding a general setting for them is too much trouble and therefore leads to more issues in the long term than it helps.

> And then I am going to have that same wish for Thunar as well. :P

Well, don't get your hopes up! I am not sure the Thunar devs are keen on implementing such a feature either. 😅
Comment 6 Bug Janitor Service 2024-07-09 03:47:12 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 7 Eduard 2024-07-12 00:20:20 UTC
Sorry late reply but I believe I do agree with most you said. Again thanks for the information! :)
Comment 8 Felix Ernst 2024-07-13 09:53:32 UTC
Good to hear that we have come to a mutual understanding and you are welcome! :)