https://bugs.kde.org/show_bug.cgi?id=475805
--- Comment #12 from Steve Vialle <stev...@runbox.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.