Bug 3212

I need this option too. KOffice generate a large number of annoying backup files (anybody 
know how to disable this KOffice behavior?).  

The problem, as I see it, is that there is no standard backful file suffix, at least in the same sense that dotFile are standard.

So why not implement it as a regexp; hide all files that either match or don't match the regexp. That way I could specify ".+(~|#)", or something similar.

Then again, we'd make most people happy by hiding just .+~

*** Bug 79248 has been marked as a duplicate of this bug. ***

Bug 79249 suggests creating and applying some common convention for the backup file names....

*** Bug 90568 has been marked as a duplicate of this bug. ***

I actually hacked the Konqueror/KFileDialog code to do this (except it had the ability to hide any file matching a glob,  not just backups, and I'll make a patch against CVS when I get around to it.

I had a similar idea and posted two example screenshots on kde-look.org: http://kde-look.org/content/show.php?content=20803

I think it's a good idea too!

Then, I would also be able to hide those hideous ~/evolution/ and ~/tmp/ folders !!!

So, it would be a filter, not regarding only to the filename but also to the entire path (as I wouldn't want ~/Projects/evolution/ for example).

I vote for it
If it does in a clean way, what should allow to hide
-> files or folders
-> according to full path
-> OR according to the name, with respect of regular expressions (*.tmp etc...)


It could make Highly Incompetents Users (HUI) feel better on their mandrake-like distro without annoying purists.
It could also prevent my mother (she barely understand what's a file) to go and get lost in /usr, /etc, /proc etc...
without renaming all system-related files, starting with a point ...

BUT We have to keep in mind this is dual to the known convention "starting with a point is a hidden file". Which is hard to apply to system files ...

Created attachment 10208 [details]
This is a patch to allow you specify glob patterns for hidden files

OK, here is my patch, and AFAIK it works. You can now control what files are hidden with a list of globs under the [KDE] HiddenFiles key in kdeglobals, or if that key does not exist (it won't in your case) then it uses the default ".*". It does some weird things like deprecate the KFileItem::isDotFile() in favor of a new isHiddenFile() (because it is now not just dot files) - I hope this does not offend anybody. In my kdeglobals, for example, I have "HiddenFiles=.*,*~". Note that this patch only changes what files are hidden; it does not add any GUI element to configure it, but if that is desired, I will add it as well. I hope this gets committed as it is my first patch ;-).

Oh yeah, one more thing: this patch only deals with file names, it is not suitable for hiding paths such as /usr. If you want to prevent your mother from browsing anything except her home dir, look into KIOSK maybe, I don't know.

That sounds interesting. But how do I apply it correctly?
The following command (executed in the kdelibs directory with the patch inside) doesn't do anything.

patch -p0 patch.diff

Can anybody help? Thanks!

Don't execute it from inside the kdelibs directory. Go one level up (e.g. the directory that contains the kdelibs directory), and then execute it. Note: this is more or less a quick hack, it won't necessarily work everywhere, but it would be good to get some feedback.

I do not think that patch #10208 is the right way.

First hidden files are hidden files and backup files are backup files. A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.

Also I do not know why it is needed to redefine what a backup file is, as backup files have the mime type application/x-trash .

Have a nice day! 

>A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.<

That's why it's configurable! Use the HiddenFiles= entry in kdeglobals. For instance, I have HiddenFiles=.*,*~

On Sunday 07 August 2005 16:36, Luke Sandell wrote:
(...)
>
> >A user might want to see the hidden files but not the backup files for
> > example when he tries to edit some of them or on contrary he may only
> > want backups to recover a backup.<
>
> That's why it's configurable! Use the HiddenFiles= entry in kdeglobals. For
> instance, I have HiddenFiles=.*,*~


I meant to have such things in Konqueror's menu (in file manager mode). I will 
not edit a file for having the backup files for a few miniutes.

Have a nice day!

>A user might want to see the hidden files but not the backup files for example when he tries to edit some of them or on contrary he may only want backups to recover a backup.< 

Well, there can only be one definition of a "hidden file." Either we are going to include backup files or we are not (a nice way this dilemma could be solved is by just including a dot at the beginning of the backup file).

What you are talking about is a way to show and hide certain types of files at certain times. That is a View Filter (see under the Tools menu), and Konqueror has those as well. Unfortunately they are not very versatile at this time.

Is the suggestion that all application should (optionally) save backup files as "dot whatever tilde"?  Or that Tools -> View Filter should be extended to include "don't show files matching pattern...."?  Or both?  Or something else again?

> A user might want to see the hidden files but not the backup files
> for example when he tries to edit some of them or on contrary he
> may only want backups to recover a backup.
 
There are several places in KDE which already have a 'show hidden files' toggle.... For example File Chooser dialog and KDevelop's file chooser sidebar. I think it is important that whatever mechanism we use for 'hiding' backup files should be toggled by that same control. That is inconsistent with the requirement quoted above.

An alternative design....
How about including a "hidden file" flag in the mime-type definition. Include a checkbox on Konqueror's file association configure page. I personally would check that box for application/x-trash and application/x-python-bytecode.

On Tuesday 09 August 2005 02:06, Luke Sandell wrote:
[bugs.kde.org quoted mail]

MS Windows has anyway a totally other way of thinking about hidden files and 
that is quite different than a file name starting with a dot. That I also a 
reason why I would prefer not to mix the two things together.

>

(...)

Have a nice day!

On Tuesday 09 August 2005 09:50, Toby Dickenson wrote:
(...)
> > A user might want to see the hidden files but not the backup files
> > for example when he tries to edit some of them or on contrary he
> > may only want backups to recover a backup.
>
> There are several places in KDE which already have a 'show hidden files'
> toggle.... For example File Chooser dialog and KDevelop's file chooser
> sidebar. I think it is important that whatever mechanism we use for
> 'hiding' backup files should be toggled by that same control. That is
> inconsistent with the requirement quoted above.
>
> An alternative design....
> How about including a "hidden file" flag in the mime-type definition.
> Include a checkbox on Konqueror's file association configure page. I
> personally would check that box for application/x-trash and
> application/x-python-bytecode.


Now (independently of this issue) there was a change in KIO to let the KIO 
slave control that a file is hidden or not.

That probably means that the isHidden() should not be changed in its meaning.
(And probably the patch does not apply anymore.)

Have a nice day!

*** Bug 111101 has been marked as a duplicate of this bug. ***

For the record, I proposed a different mechanism for backup files to get rid of the clutter in Bug 120313.

I'd like to throw in my vote for Nautilus-style .hidden files, perhaps by merging the existing Kubuntu patch which adds such to Konqueror and KDE file dialogs.

While setting up Kubuntu for my brother, I noticed that they had used .hidden to clear out most of his root (I believe it only contained home, media, and usr) and, despite being a very technical person, my first thought after realizing how it was done was "What a great idea." for the following reasons:
1. .hidden can be customized folder-by-folder
2. No effect on my rootly duties since they're done through a terminal window.
3. Already supported by all my GTK+ 2.x apps. One file works for both.
4. Less clutter means less searching as I bounce around the filesystem.

It has it's flaws. For example, it can't be set on a per-application or per-user basis, but I think those are outweighed by the fact that it's already supported by GTK+ 2.x and Nautilus.

*** Bug 121195 has been marked as a duplicate of this bug. ***

Implementing the proposial at #142091 would probably be the best way to fix this !!

Bug 142091

*** Bug 153881 has been marked as a duplicate of this bug. ***

Like ppenz suggested to me, this is related to kdelibs. If implemented it could be used by dolphin (the current file manager).

Unfortunately, making everything configurable isn't a solution to every problem; it bloats the configuration dialogs or introduces hidden config keys which only solve the problem for the 5 users in this report.

I do see the need for a way to hide backup files and other such unwanted files [but let's not talk about hiding entire directories in this bug please, that's unrelated].

The purpose of backup files is that users _know_ they are there, to recover a document after a crash or a wrong deletion or overwriting of a document. Therefore they should not be hidden by default, unlike dot files.
So this means a possible solution would be to have "[X] Show backup files" in addition to "[ ] Show hidden files" (separate, because enabled by default).
This brings me back to Peter: what do you think about this? I know you might not like yet-another-menu-item... (and I'm not sure it's the best solution either).

Well I guess another solution is improving the dirfilter plugin, but then it'll be konqueror-only, no option in dolphin. That's a possibility though, if Peter prefers to keep Dolphin simpler (less configuration).

Note for comment #1: you can configure koffice so that it puts all backup files into a single directory, no more pollution of the real user directories.

@David: I'm not sure honestly speaking about this issue. I don't think the solution is yet another menu entry "[ ] Show backup files". E. g. the next request might be "please also allow to hide Amaroks *.m3u files" or "Digikams *.db" files.

What might a nice solution would be providing a general filter string per directory. This could be stored inside the .directory entry and filtered on application side. So we would have a generic solution that does not only work for backup files. Any thoughts?

@Peter: if you mean a regex operating on filename (basename) with "general filter string" this would be a great solution for me, solving all my needs.

filter string sounds good to me; simple and powerful.

there is nothing to stop an interested party from making a simple gui editor for the filter string in a separate window at a later date that helps less capable users choose which types of files they want to hide. that way you can avoid cluttering the main window with checkboxes and options as desired.

Has anyone considered just adding support for obeying the .hidden file that Nautilus already supports? I think Kubuntu even has a patch for that.

Some information about the Nautilus .hidden file:

http://ubuntuforums.org/showthread.php?t=789684

Another option might be extended attributes so that the fact that the file is hidden becomes metadata of the file, and moves with the file if it's moved, for instance.

http://en.wikipedia.org/wiki/Extended_file_attributes

Extended attribute hiding does have it's benefits as any Windows user knows. It IS nice to be able to hide a file without renaming it and, in the process, confusing any application which depends on it.

However, I'm sure there are arguments against it to. I haven't considered it, so I'm currently in "either would be fine" mode.

Aha! One argument I didn't consider (since I use KDE with one or two GTK+ apps) is that a sane ~/.hidden implementation would be cross-compatible with Nautilus, thereby reducing hassle for integrators and any users who, for whatever reason, like to use both Nautilus and DolphinPart.

That is really something I do not understand: why storing directory view information inside the directory itself???? 

It makes only sense when this view is the same for every user reading the directory. Otherwise, it is a bad design.

"Hidden" files, backup files I don't want to see, icon view, list view, background color... All these things that define the way the user want to see a specific directory, should be stored outside of that directory, in some sort of user-specific database or configuration file.

This mechanism should not prevent of using .directory or .hidden files, provided that it is clear that these files define the view for all users.

My two cents.

Another issue (as noticed on MacOS X a while back with their .DS_INFO files) is that they can expose valuable info to an attacker when web or other types of file servers are improperly configured to serve them them. When all the metadata is stored in the user's directory and has a consistent set of permissions this is less likely to happen.

From my perspective, I really don't like the store-the-file's-extra-attributes-in-another-file approach. It's complicated to handle and keep updated when the files are renamed or moved.

I think the best approach would be two-fold.

1. Use an (xattr) attribute of the file to determine whether its hidden or not. A user can bring up the individual file properties and set this attribute. This is a good solution for a file-centric approach that transfers the attributes with the file when copying to other disks/systems, etc.

2. Use a regex pattern list ala adblock, both globally-defined for the system, for example any file starting with a dot, as well as user-defined for the user, for example I don't want to see any filename~ files. This is a mass-effect approach that is system/OS-centric. The user configuration can override the system global configuration for users who don't want their dot-files being hidden.

With #2 implemented, it wouldn't be that hard to add support for including other files, if they exist, such as a .hidden file. For example: "#include ~/.hidden". However, I'd like to re-emphasize keeping a separate list of individual files is not an elegant way to do this. It would simply be included for compatibility reasons.

I agree with gambas: hidden or not hidden is not something you want to have per file or per directory but it is per view. Each user can decide which view he wants to use where, even two different views in different windows at once.

So I think it makes sense to store a filter regex in a central, application specific configuration. Konqueror e.g. should store the filter regex in its "view profile" to make it easy to switch between views.

I fail to see the purpose of saying, it's okay if a file or folder is hidden if it has a dot in front of it, but otherwise, it's a bad thing. All the leading dot is in the Linux context is a file attribute that has the side-effect of changing the file name. This is very similar to Windows file extensions. Changing the name, such as ending in .txt or .exe, changes the file type. Frankly, the fact that you can't configure this leading-dot=hidden-file/folder seems to exude UNIX-quirkishness to me. (Yes, I made up a word.)

Frankly, I think developers or system administrators should have the option of hiding individual files or directories without leading periods in the filenames if they want them hidden. Of course, users should also be able to view hidden files or folders if they choose. If we're in the business of hiding ad-hoc files or directories, it makes sense that that metadata be stored in an extended attribute (xattr) rather than in a separate file. This is similar to if I add a dot in front of a file name and move it, I don't have to update a configuration file somewhere to keep it hidden.

My #2 sounds very similar to your ideas Gerd/Gambas, except that there would be two levels. One which is a system-wide filter list, which BTW already exists as a de facto standard through leading-dot-filename=hidden-file/folder notation. This could be implemented as a global configuration file which empowers the system administrator at the expense of the user, or perhaps a set of default user settings. (i.e.- This is what most users want hidden, but you can change this.) The latter approach leaves the user in charge but makes it hard for the system administrator to role out a new file-hiding standard. This may be a good thing or not depending on your perspective.

Finally you would certainly also have a per-user configuration set of filters that could work as a view as you stated Gerd.

My main worry with a filter regex is that it could get unwieldy very quickly and, depending on how it's implemented, could be useless anyway.

For example:

.+(~|#|\.bak)|/home/ssokolow/StepMania

Imagine how that would look as the number of special-case files like ~/StepMania grew. As for "useless", it's utility depends on being able to match against the entire path... which is rather unlikely in a well-designed system.

Hence why I think that, if there is a filter regex, it should be in addition to something based around xattrs or .hidden. I do agree that, if it's going to be "done right", xattrs are the way to go. However, keep in mind that per-view hiding is outside the scope of the .hidden design since it's basically a way to duplicate Windows' familiar "Hide a file without renaming it" ability.

While I do agree that renaming files to mark them hidden is a quirky hack and as bad as using extensions to identify files, I don't like the idea of a system-wide filter list at the expense of the user. I envision all sorts of problems because applications could start basing their filenames on the most popular hiding regexes, resulting in confusion for users with non-default ones. Therefore, I think it'd be best if anything global was an /etc/skel-ish default rather than being an actual runtime-checked config setting.

In short, I suggest this:
- Per-user filter regex (perhaps stored in a DE-independent /etc/skel-able file)
- System-wide xattr-based hidden file attribute (Possibly with a .hidden compatibility mode)

Well it doesn't have to be -one- regex, consider that we could have a configurable list of hidden files patterns.
(Most users know patterns like *.bak more than real regexps like .*\.bak)
So a solution could indeed be a configurable list of patterns, like .*, *~, *#, *.bak, *.db, *.m3u  (the comma is just
for this mail; graphically it would appear like a list box with 6 items and add/remove buttons).
I guess it solves my use case of "using a backup file even though it's usually hidden", since the user could
simply toggle "Show Hidden Files" temporarily for this.

The "configurable list of patterns" idea has nearly come full circle to my suggestion in comment #21 that it be based on mime types. application/x-trash ("Backup Files") already comes with a fairly long list of patterns including *~ and *.bak

The more that I think about this the less I like it.  

Should hiding be an operating system thing, a filing system thing, an installation thing, a (creating) application thing, a (viewing) application thing, a view thing, or a user thing?  Or some evil combination of the above?  We could have a hierarchy of configurations.  >:->  There must be a dozen places that you can insert "vi" options.  

Option A)
"ls" already has "-a" and "-A" options.  Let's just badger all application maintainers to create dotted backup files.  

Option B)
Keep the current drop down menu "View".  Replace, "Show hidden files" with a sub menu, "hide files =>" and have a check box for each of; dot files, bak files, tllde files, [[every other daft convention that you can think of]] and finally a check box for a user's regex expression.  The default should be to have "dot files" checked and all others unchecked.  

Just my 2 cents worth.  ;-)  

Mostly in response to #48: Presenting a view of the filesystem that facilitates easy file management is the role of a file manager. A flexible mechanism to ignore a particular set of files helps out in this ares considerably. Whenever I launch konqueror to organize a directory I must first delete all of the stupid files (for me this is more than just backups, LaTeX generates a large number of auxiliary files that just clutter up the view). Disk is cheap, cleaning out these auto-generated files every time I want to organize my content is annoying and gets in the way of doing actual work.

To me, both supporting the existing .hidden approach and a configurable list of globally applied "backup" patterns (or globs) [I would vote for a separate "[X] Show backup files" menu item, but would be nearly as satisfied if they were all lumped together as "hidden" files] meet an appropriate expectation level for power users and could be made sufficiently obscure to avoid annoying individuals who do not want this feature. A general "filter contexts" submenu would be a nice general solution, but that is probably over the top and would get in the way of users who are not interested in using it so I am not pushing for that.

In summary: Several of the commenters here were interested in hiding non-backup files. Even if all application developers could be convinced to make their backup files dotfiles, this bug would not be fully resolved since that would not cover all of the desired usage patterns. It is useful and appropriate for a file manager to implement a feature that cleans up the user's view of the filesystem. Perhaps a better title for this bug is "Option to hide clutter as well as dotfiles".

Thanks for listening to my rant.

I'm with Stephen on his conclusions and with David Faure on the point that you don't want a single regex, but a list of regex expressions.

I also like Toby's idea that we could store the hidden file regex list as part of the file-type/mime-types list. What's also good about this approach is that it is defined at the system level, but users can customize, so it empowers the users by getting around the idea of users being at the developers leading-dot preference whims.

So that would mean you could right-click on the file, get the properties of any file you have rights to, and hide (xattr) it.

Or, you could right-click a file, select the file type definition, and check a box to hide all files of that particular type. You could also create a new file type to cover any special "filename pattern" or regex and hide those as well.

The first way is a file-by-file system approach that is portable, between filesystems supporting xattrs. The second way is a user preference approach.

The only downside is that you don't get the flexibility of having multiple views that you could quickly switch between to hide different sets of files. Can anyone think of why that would be a desired function?

On a well-organized system, I can't really think of a clear benefit to multiple saved views. Perhaps as a way to switch between viewing different types of files in a source tree, but that tends to be easily done using the filter box.

The main benefit I can think of would be for organizing an "unsorted junk" folder full of stuff that you let build up... but even then, setting "sort by type" and/or using the filter box (possibly with a split view) seem to solve the problem perfectly well.

I'm trying out kde4.2beta2 and like the implementation in the desktop folder > folder view settings > filter > hide files matching....  Very useful. Something like this in dolphin would be great.

Another possibility could be that, like KOffice, backup files could be optionally rerouted to a set folder.

Thanks for pointing the folder view hide files thing out, Geoff. I too hope that functionality will come to Dolphin.

Couldn't this be resolved with .hidden files per this issue: https://bugs.kde.org/show_bug.cgi?id=64740 ?

.hidden files are useful, but they don't let you say "Hide files which match this pattern ANYWHERE ON THE FILESYSTEM". (You'd need to create and maintain a .hidden file for every directory on your system)

This is about a global pattern ignore list. .hidden files are directory-local pattern ignore lists.

Regarding my earlier comments in #50, of course, the user would have an option in the interface to "show all hidden files", and thusly switch between the view that hides the files marked (xattr) as hidden, and the file types (mime) option which are hidden.

*** Bug 195767 has been marked as a duplicate of this bug. ***

*** Bug 201678 has been marked as a duplicate of this bug. ***

*** Bug 204428 has been marked as a duplicate of this bug. ***

That is a good point,
Applications create backup files so that users can find them.

Backup files clutter the enviornment for users.

Regarding the argument: yet-another-menu-item ... [ to twiddle a setting few people care about]
We don't need a menu option, IF there is a global kde settings editor, like firefox's about:config.  Is there such a thing? and can we make it?

.hidden file compatibility with gnome would be nice.  Does this work by having a list of files in it?

Extended attributes support would be nice,

regular expression method to hide files would be nice too (we have a filter to SHOW files,, why not have a negative filter too?)

Basically, lets just get the features and not worry about the GUI configuration, it should be handled in a glob of other configuration info.

I think the last thing we want is a hidden config options editor like about:config, gnome settings, or regedit.  I think it a bad approach and once we set the precedent we will end up with a lot of untested, unstable, hard to find, and hard to understand options (like we have in all of those cases).  Hidden options should be hidden only because they are known to be incomplete, unstable, working poorly, or no one has found a good place for them yet.  Options that are intended for people to use normally should be properly organized.

A general, configurable, with memory of configuration(for context (which folder), application, and global settings) File hiding filter.

If I get a build environment up, I'll start playing with your patch. (need somebody in Seattle area who can figure out how to make kdesrc-build to work)

===

 Then these should be properly tested options only, It can't hurt to
 have another way to do stuff.
 It works for firefox--hidden was the wrong word. --
 Less floofy --mostly text-- managed-- method to configure options that
 people would otherwise have to search tab by tab to find.

 This about:config like configuration method would allow us to have
 options that power users need, and make it so that people don't file
 20 million feature requests for the same feature--they can find
 it--problem solved once and for all.

 So, In short, I agree fully that proper organization is important, and
 a column in the table could explain what it does, and there should be
 error checking on these configs.  I fould find this easier to use than
 tabs or editing config files. Telling people to edit config files is
 much worse than telling them to edit the list view of the options.
 Starting to feel bad about continuing here, Will file new request.

I'd like to add my support for the original request (over 10 years old now - impressive!).

i want a glob list of file/folder names and paths to hide.

this way i can hide the stupid folder in my home directory, whose path is hardcoded in some stupid application (let’s call it appX), and this way i can hide all backup files, no matter where they are.

the file would then look like this:
~/appX
*~
*.backup
*.bak

This is the oldest bug/wish I've cast my vote on :D Fortunately I really like History! I came here after finding that there is no way in dolphin to hide those annoying (but usefull) backup files that keep poping up all over the place.

PS: Hello visitor from the future ;)

I too ended up here after looking for a way to do this.

A user here http://forum.kde.org/viewtopic.php?f=17&t=82350 gives a workaround:

Settings -> Configure Kate... -> Open/Save -> Advanced -> add "." (dot) to "Prefix" under "Backup on Save".

Very bad bug.

I'd really appreciate it if somebody worked on this; it's an extremely annoying bug.

Three years later and no news to this? Would be really great if this would be fixed.

Are people still interested in this feature ?

There a mimetype x-trash that seems to cover most extensions you are referring to.
And this is editable using `keditfiletype5 application/x-trash`

It might only come with Dolphin with KF6 though.

(In reply to Méven from comment #70)
> Are people still interested in this feature ?
> 
> There a mimetype x-trash that seems to cover most extensions you are
> referring to.
> And this is editable using `keditfiletype5 application/x-trash`
> 
> It might only come with Dolphin with KF6 though.

It would be nice to be able to configure what mimetypes should be hidden (so that I can then create a custom mimetype that matches the folders/files I want to hide). For example, I would like to be able to hide all folders called `__pycache__`. Mine may be a somewhat niche wish, though.

(In reply to Méven from comment #70)
> Are people still interested in this feature ?
> 
> There a mimetype x-trash that seems to cover most extensions you are
> referring to.
> And this is editable using `keditfiletype5 application/x-trash`
> 
> It might only come with Dolphin with KF6 though.

Yes, but how to specify that that mimetype should be hidden by Dolphin?

… surprise e-mail  …

Yeah, 20 years passed, konqueror switched to dolphin, but while I can easily hide/show
   .something.txt
(Ctrl-H in dolphin) there doesn't seem to exist an option to hide
     something.txt~

(In reply to Martin M from comment #72)
> (In reply to Méven from comment #70)
> > Are people still interested in this feature ?
> > 
> > There a mimetype x-trash that seems to cover most extensions you are
> > referring to.
> > And this is editable using `keditfiletype5 application/x-trash`
> > 
> > It might only come with Dolphin with KF6 though.
> 
> Yes, but how to specify that that mimetype should be hidden by Dolphin?

It wasn't clear.
I was suggesting it could be built-in (as suggested x-trash), like having a checkbox "[x] also hide application/x-trash files when hiding files".

A built-in mime-type has the advantage of being easier to implement and less complexity exposed to the user.
Since the mimetype extension association is editable by users, power users will be able to leverage it, although less easily than if it was in the config UI directly.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/1300

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/558

Is there a point in keeping tickets like this open for 23+ years? I keep receiving notifications for several of them. If a problem isn't resolved in, let's say 5 years, it probably never will or the affected component will be deprecated and replaced with something else.

(In reply to Alvaro Aguilera from comment #77)
> Is there a point in keeping tickets like this open for 23+ years? 

Yes given this has had many duplicates, has a bunch of CC users and votes.

> I keep receiving notifications for several of them.

Feel free to un-CC yourself, this is expected behavior.

> If a problem isn't resolved in, let's say 5 years, it probably never will or the affected component will be
> deprecated and replaced with something else.

Well that's not true, at least most of the time.
Only devs can make such decisions.

Here I am thankful this was still opened, or I wouldn't have worked on it.

And the fact you receive emails like "A possibly relevant merge request was started" means some work is underway to implement the feature.
If you are CC to this BUG you should rejoice.

- Do editors in 2023 still save files like sth.txt~, sth.txt.bak and similars? 

  Yes, they do. 
  Some skip that when working inside git/hg/svn/… folder, some allow
  to use separate folder, but such files are still fairly frequent.

- Would some users prefer not to see those files?

  Yes. For example myself.

- Does KDE allow user to manage which files are hidden, and which are not?

  No, it doesn't. 
  There is option to show or hide „Hidden files” but no way to influence
  which file is considered to be „Hidden”.

So functionality-wise bug is just as sound and valid, as it was when it was reported.

Projects make various priorities, open-source projects even more so (considering people come to work on what they fancy or what they find troublesome). Some bugs are less lucky. But if there is to be any hope, the open issue means the thought of doing sth is not abandoned.

And it is somewhat heart-warming to get mail that sb. started working on issue I reported 20 years ago (OK, OK, I reported one of the early dupes, not this one)

Git commit 7f3967cf38f8ab707681981dd0bc6b220c3dbf83 by Méven Car, on behalf of Méven Car.
Committed on 17/06/2023 at 07:09.
Pushed by meven into branch 'master'.

Hide application/x-trash files following showHidenFiles

M  +39   -1    src/kitemviews/kfileitemmodel.cpp
M  +6    -0    src/kitemviews/kfileitemmodel.h
M  +26   -6    src/kitemviews/private/kfileitemmodelfilter.cpp
M  +8    -0    src/kitemviews/private/kfileitemmodelfilter.h

https://invent.kde.org/system/dolphin/-/commit/7f3967cf38f8ab707681981dd0bc6b220c3dbf83

Just wanted to note: To unhide any of the file extensions affected by this change / Dolphin 23.08, use "File Associations" in System Settings to create a new file type for them. To the contrary, removing *.old and *.bak from the "application/x-trash" association still kept them hidden (which makes sense since the file types probably fell back to the system association, which is still "application/x-trash")

Might be stating the obvious, but I think this tip might help someone stumbling into this in future. I was one of the users purposefully renaming files to end in *.bak or *.old and naturally would like to keep them visible.

Git commit c52396aec3047811d5150d621b371eaf92c3cfc6 by Albert Astals Cid, on behalf of Méven Car.
Committed on 16/09/2023 at 02:23.
Pushed by aacid into branch 'master'.

Reintroduce KCoreDirLister::setMimeExcludeFilter

Partial revert of 8e452cde003c14ad70c53c5874fc195a6178d887

M  +14   -2    autotests/kdirmodeltest.cpp
M  +11   -0    src/core/kcoredirlister.cpp
M  +22   -0    src/core/kcoredirlister.h

https://invent.kde.org/frameworks/kio/-/commit/c52396aec3047811d5150d621b371eaf92c3cfc6

(In reply to Luke Horwell from comment #81)
> Just wanted to note: To unhide any of the file extensions affected by this
> change / Dolphin 23.08, use "File Associations" in System Settings to create
> a new file type for them. To the contrary, removing *.old and *.bak from the
> "application/x-trash" association still kept them hidden (which makes sense
> since the file types probably fell back to the system association, which is
> still "application/x-trash")

How do I do that in XFCE? I would very much like my .bak and .old files to be visible in Dolphin.

Update: I found a workaround which works in XFCE to unhide .bak/.old files in Dolphin.
Create the file /usr/share/mime/packages/backup.xml with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
    <mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="application/x-backup">
      <comment>Backups</comment>
      <generic-icon name="application/x-backup"/>
      <glob pattern="*~"/>
      <glob pattern="*%"/>
      <glob pattern="*.bak"/>
      <glob pattern="*.old"/>
      <glob pattern="*.sik"/>
      <icon name="application-x-trash"/>
    </mime-type>
</mime-info>

Then run:
sudo update-mime-database /usr/share/mime

Please do not re-open bug reports marked as fixed.

Please revert this. This 100% goes against user expectations on a unix system.

(In reply to Daniel Scharrer from comment #86)
> Please revert this.

This behavior will be off by default in next dolphin version.
See https://bugs.kde.org/show_bug.cgi?id=475805