.bak files are only visible if I choose to show hidden files. STEPS TO REPRODUCE 1. Open a folder containing files including .bak files. 2. Look at the files. OBSERVED RESULT 3. See no .bak files EXPECTED RESULT See all files that are not hidden ADDITIONAL INFORMATION This is dangerous because unexpected. I could move files then delete a folder thinking there is nothing useful left in it, then find I would like to have a backup file later.
See the behaviour in Fedora 38 and Neon Unstable... I'd see it as a question of expections: Are you consciously/deliberately making a .bak copy of something important - or wanting to save the .bak copies that other program (an editor?) might make in the background for you. I think Dolphin is hiding the latter... I'll flag as confirmed, even though I might find it not a bad idea...
I think the reasonable thing to do is to conform with standard behavior on linux, which is to only hide files/folders starting with a dot... (this is also what `ls` does). Other kinds of behavior probably would be surprising to users. https://en.wikipedia.org/wiki/Hidden_file_and_hidden_directory
This apparently also affects files ending in ".old" and "~", along with whatever else is now randomly considered "hidden" with complete disregard for unix/linux conventions. These are not hidden files, they are relatively standard conventions for _backup_ files. The option is not called "show backup files", now is it? Please split this from the "show/hide hidden files" functionality, this (recent) change is misleading, confusing, undocumented, and _extremely_ annoying.
This change was done to fix a long-standing and much reported bug. Please look at https://bugs.kde.org/show_bug.cgi?id=3212 to understand why this change was made. If you don't want this behaviour on your system, look at this comment https://bugs.kde.org/show_bug.cgi?id=3212#c81 which explains how to go back to the old behaviour. It seems a bit like we are in a situation in which different people want different and conflicting behaviour.
(In reply to Felix Ernst from comment #4) > This change was done to fix a long-standing and much reported bug. It's more accurate to describe that as a long-standing feature request, the eventual response to which was explicitly argued against on several occasions by various users for essentially the same reasons being expressed here. > this comment https://bugs.kde.org/show_bug.cgi?id=3212#c81 which explains > how to go back to the old behaviour. Inventing spurious mime-types should not be necessary, even if it is a functioning workaround for this bug. Another workaround would be to stop using dolphin, but I don't really want to do that, either. > It seems a bit like we are in a situation in which different people want > different and conflicting behaviour. Which to be expected and is probably why the original request in https://bugs.kde.org/show_bug.cgi?id=3212 was for an *option* to hide backup files as well as dotfiles, not for a misfeature treating them both the same.
(In reply to Felix Ernst from comment #4) > This change was done to fix a long-standing and much reported bug. Please > look at https://bugs.kde.org/show_bug.cgi?id=3212 That's not a bug, it's a 20+ year long discussion on how best to implement a *feature request*, and whether or not it's even a good idea to begin with. What we have here isn't a fix for something that was broken, it's a departure from behaviour that has been standard since KDE 1.0, and followed the example set by such truly obscure file management utilities as 'ls' and the rest of coreutils. > It seems a bit like we are in a situation in which different people want > different and conflicting behaviour. It's a situation where this was requested 23 years ago, and never implemented because nobody could agree on what beyond dotfiles, if anything, should be hidden. Even after the revival this year, nobody at all suggested x-trash be lumped in under the existing "show hidden files" functionality, the request was for *user defined* hidden files. Even Méven's initial proposal to use x-trash mentioned it having it's own toggle... Which for reasons unexplained, it didn't get. What exactly is a hidden file now anyway? Traditional *nix dotfiles? Trash files according to MIME? Backup and temporary files? Anything that doesn't have a defined MIME type? Does what is visible in dolphin depend on the phase of the moon, or just what's considered an "uncluttered view" this week? If an option to hide backup files is really considered necessary, please either provide a visible and documented option to disable it (i.e. not notes on creating random extra mime types buried in an ancient feature request), or move it to it's own "show/hide x-trash mimetype" toggle.
This is a tragic bug. A file manager hiding files from the user, and with no option to toggle this behavior.
Which application is creating those .bak files? Are those files created in a context in which the application author might expect users to directly interact with the file? Is the file created in a visible path in the user's home directory or in a path that contains hidden folders?
(In reply to Felix Ernst from comment #8) > Which application is creating those .bak files? Are those files created in a > context in which the application author might expect users to directly > interact with the file? Is the file created in a visible path in the user's > home directory or in a path that contains hidden folders? 1. All sorts of different applications do that. 2. The point of a backup file is that it provides a backup. For the user. To use. 3. That varies, too.
I really can't tell if you are trying to be snarky. Please let me know if you would prefer me to not try to get the information to move this issue forward. > 1. All sorts of different applications do that. Please give me some names. > 2. The point of a backup file is that it provides a backup. For the user. To use. That's not universally true. An application might create backup files for internal use for example because it knows that an operation might leave a file in a corrupt state under some circumstances. The application would then restore the file from the backup. > 3. That varies, too. Give me the details then.
(In reply to Felix Ernst from comment #10) Hi Felix! Just trying to pitch in to the conversation here. In my case my own files got hidden right in front of my eyes when I was trying to back them up so they don't get overwritten when pasting other files with the same names. No other app was doing it, it was me manually renaming the files. I was concerned because after a month or more I could forget about the backup files, and if I were to look for them via dolphin, I wouldn't find them. I'd have to remember that I made them, and my memory isn't my best asset. I think people who've been using Linux for a while are used to ".bak" files and wouldn't expect them to be hidden. Like others in the discussion here. Dolphin is now deciding what files I should see and what files should be hidden - from me, who at the end of the day am the rightful owner of those files. I think for the sake of some users being bothered by the "clutter" created by backup files, we're reducing the real and necessary functionality of an important tool like dolphin to a mere toy. For me this breaks the "powerful when needed" motto. Usually tools that create backup files, like Emacs for example, can be configured to create those files on a certain path on disk, so they don't pollute the drive randomly. And if they don't have that option and create backup files all over the filesystem, don't you think that's the problem of the tool itself, and not something dolphin should hide? If anything Dolphin should show you the files so you could observe that messed up behavior and address it with the guilty application. Please note that at the end of the day I'm just a user expressing my opinion. I'm not trying to start a fight or to tell you what to do, I'm not making any "demands". I know you don't owe me anything and I'm not trying to be entitled here. I'm just a fan of dolphin and a long time user, but in the end ofc do what you think is right for you and for Dolphin itself.
(In reply to Felix Ernst from comment #8) > Which application is creating those .bak files? Are those files created in a > context in which the application author might expect users to directly > interact with the file? Is the file created in a visible path in the user's > home directory or in a path that contains hidden folders? I really don't see where any of this relevant. It's not the job of a file manager to predict the intent of other applications, but rather to provide an accurate view of the filesystem to the user. But, if you insist: * vi, diff and cp * Yes. Filenames provided from user input. * A first-level subdirectory of ~/, containing no traditional hidden files or directory elements. In the case that led me here, no application decided the names for the files I was working with, and "extensions" were arbitrary and supplied by the user... As is the norm on unix-like systems where file type is primarily determined by magic number rather than vestiges of MS-DOS "8.3" naming conventions. IOW, *I* created files with those extensions, as I have done quite happily for the last 2+ decades before this feature turned up, and having them suddenly vanish for no documented reason, contrary to the behaviour of every other file manager in existence, wasted considerable of my time. Filenames beginning with "." being treated as hidden is a well understood, well documented feature on unix-like systems, as established as the "hidden" file attribute in DOS or Windows. Files suddenly disappearing from view based on an arbitrary list of filename patterns buried in a rarely used mimetype is anything but, and leads to *surprises* for the user. Surprises are the _last_ thing I want from a tool like a file manager.
(In reply to dncrash from comment #11) Thank you for the information! >Please note that at the end of the day I'm just a user expressing my opinion. >I'm not trying to start a fight or to tell you what to do, I'm not making any "demands". You didn't come across as impolite to me! I hope I didn't make you feel like you needed to clarify this. :) >Dolphin is now deciding what files I should see and what files should be hidden - from me, >who at the end of the day am the rightful owner of those files. I am not sure if you are aware, but there is an action called "Show Hidden Files" in Dolphin that will make sure that the view will always show all files that Dolphin can see. So while it is true that they are being "hidden" (in some sense of the word), Dolphin doesn't really prevent anyone from using these files. >Usually tools that create backup files, like Emacs for example, can be configured to >create those files on a certain path on disk, so they don't pollute the drive randomly. >And if they don't have that option and create backup files all over the filesystem, >don't you think that's the problem of the tool itself, and not something dolphin should hide? In an ideal world this would certainly be the best solution. The tool should hide files that the user isn't supposed to interact with or which needlessly clutters folders that the user might actively interact with. Some users did however want us to hide them in Dolphin, so I am currently trying to think of a plan that makes everyone happy.
(In reply to Felix Ernst from comment #10) > I really can't tell if you are trying to be snarky. Please let me know if > you would prefer me to not try to get the information to move this issue > forward. > I'm not trying to be snarky. Some frustration with a lack of understanding that seemed to be reflected in your questions may have crept into my tone. Sorry. > > 1. All sorts of different applications do that. > > Please give me some names. > The one that provoked this report was Ardour. Over the past thirty years I have used many others. I have never seen the need to keep a list. > > 2. The point of a backup file is that it provides a backup. For the user. To use. > > That's not universally true. An application might create ... > And if the application doesn't want the user to mess with them, it can create them hidden. > > 3. That varies, too. > > Give me the details then. You don't need the details, because they would be an incomplete list based on my use and what I have noticed and found interesting enough to remember. You need to understand that there is a difference between a hidden file and a backup file, and that there are an indeterminate number of ways of making use of that difference. If you want to make everyone happy, you need to respect the difference. If you want to make the people who want backup files hidden happy, you need to give them an option to hide them.
(In reply to Felix Ernst from comment #13) > I am currently trying to think > of a plan that makes everyone happy. The obvious answer is right there in the feature request: "it could be built-in (as suggested x-trash), like having a checkbox "[x] also hide application/x-trash files when hiding files"." Why continue to drag this out with diversions into what "application author might expect" and "user isn't supposed to interact with"? That's up to the application developer to deal with (usually using hidden "dot" files or directories), and cleaning up after programs that make a mess is none of dolphins business. If you want to please both those who want to keep the old hidden file definition and those who want x-trash (or some other list) hidden as well, what's the problem with simply adding a configuration checkbox as proposed? Worded as above, it even documents which mime type to edit if you want finer control over exactly what is hidden.
A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/695
Git commit 9691afbc507ee480d4d129a6fff90b6b926aed62 by Méven Car, on behalf of Méven Car. Committed on 13/01/2024 at 10:07. Pushed by meven into branch 'master'. Add setting also hide application/x-trash files when hiding hidden files M +8 -15 src/kitemviews/kfileitemmodel.cpp M +4 -0 src/settings/dolphin_generalsettings.kcfg M +12 -0 src/settings/viewmodes/generalviewsettingspage.cpp M +1 -0 src/settings/viewmodes/generalviewsettingspage.h https://invent.kde.org/system/dolphin/-/commit/9691afbc507ee480d4d129a6fff90b6b926aed62
*** Bug 484449 has been marked as a duplicate of this bug. ***