GNOME Bugzilla – Bug 311010
better handling of hidden and backup files
Last modified: 2021-06-18 15:29:31 UTC
Nautilus has invisible files feature (.hidden, .* *~), but it complicates some operations. Following thins should be improved: 1. Make hidden pattern configurable. 2. Nautilus should report invisible items in status bar: %n items (%n invisible)... 3. Add new preferences option: Operations with invisible files: Join and use (probably default) / Ignore / Delete during file operations / Ask user. It should affect following operations: 3.1 Move and rename files with invisible backup. 3.2 Deleting a directory (and maybe moving) with invisible files. 3.3 Select all. 4. Orphan back-ups (file~ without file): Show them with special label (broken back-up). 5. CD burning - report about invisible files or show them by default.
There should also be a way of opening the backup file, perhaps by right-clicking and then going "Open backup version with...".
I'm going to close bug 138440 as a dup, but see that bug for some reasons why this needs to be implemented, especially for move/delete operations.
*** Bug 138440 has been marked as a duplicate of this bug. ***
Also see bug 138440 for info on handling of duplicate backup file names when moved to trash.
Thanks for your productive input. We should be able to incorporate most of these proposals into Nautilus 2.14. We could also add thumbs.db to the default pattern for invisible files, as suggested by bug 315465.
*** Bug 315465 has been marked as a duplicate of this bug. ***
Mass changing Nautilus version for bugs that have GNOME 2.13 version info.
(In reply to comment #5) > Thanks for your productive input. We should be able to incorporate most of these > proposals into Nautilus 2.14. We could also add thumbs.db to the default pattern > for invisible files, as suggested by bug 315465. And desktop.ini, and so on...
Is this really that hard?? You already have the functionality built in for .hidden files, and you have system-wide preferences for each user in Nautilus. Why can't we add the same file names to a single system-wide file that applies to all directories? You should eventually add something to File Management Preferences so regular users can change this list without editing a text file, but that's not the real important part. Just providing the functionality would be nice. Should Stanislav's requests be broken up into multiple bugs?
Created attachment 134351 [details] [review] Simple patch to hide files by glob pattern I just created a patch to make files hidden by matching against a global list of glob patterns. It's pretty simple minded but it works.
I tried out the patch by Stephen Kennedy and it is working great. What needs to occur before this can be integrated into nautilus?
Changed version, I think it's still applicable.
Comment on attachment 134351 [details] [review] Simple patch to hide files by glob pattern Cursory glance shows the patch doesn't follow our coding style in a few places (declaring variables in the middle of blocks, spacing, etc). As for if the idea's even sane, I'm not so sure we should be plucking those values out of Gconf rather than just hardcoding them somewhere, since the subset of files that should be hidden in this way is very small (Thumbs.db, desktop.ini, __MACOSX). You also run into the problem that GTK+'s file chooser would still show these files, so it somewhat makes sense to do this in GIO rather than Nautilus itself.
Thanks for the comments. I disagree about a hardcoded list. The key is only read once unless it changes so efficiency is not an issue. Also I think it's crazy to have to recompile everything or wait for a new release if some new program starts creating some other pattern not in the list. I would imagine there are all kinds of issues getting something like this into GIO because we're then stuck with a gconf dependency or hardcoded list neither of which are acceptable IMHO. The code is small enough that it could be used as a passthrough backend for the file chooser, but to honest I don't care enough about this. These dialogs are transient and the extra items don't get in the way, whereas they absolutely annoy in the nautiulus windows. If I make the patch conform to the coding style, would it be acceptable?
Well, if you think about the behavior it enables, it's no bother for someone to write a single line script to change it to "*" in GConf and we get an influx of a thousand bugs of people asking what happened to their files or why their disk is full but they see no files or why they can only see them if they're viewing hidden files. The list of files that 'should' be hidden in this way is tiny. It _very rarely_ changes. If someone has a program that produces files they don't want to see, they can use the already existing '.hidden' infrastructure. We do major releases every six months, and if such a change should become necessary in the future it's no bother for someone to add it to a minor update since it's a single new line. And again, it's not even Nautilus' concern. It should be in GIO if it should exist at all so that all GIO file managers gets it automatically and not have to chase around patching everything every time the list changes. It'd be as simple as adding a key like "standard::is-foreign-hidden", or just adding it to the existing standard::is-hidden key.
The proposed changes seem controversial. Personnaly, I'm all for: 1. A user-configurable list of patterns that define files as hidden. I would recommend to have a default list of patterns that hide a list of common Windows cruft (which you get when downloading zip archives from windows users, for instance), as well "lost+found" directories. ".*" could be hard-coded and impossible to disable since it's a platform standard, but I suggest the "*~" pattern (currently hidden in Nautilus) be part of this user-configurable list. "*" and "*.*" could be black-listed (ignore when specified by user), thus preventing the major head-ache over users mis-configuring this. Note also that the list of patterns could be a gconf-only option, if typical end users configuring it is not encouraged. 2. An information in the status bar regarding the number of hidden items in the current view. Not sure if "normal" users should see this information. This may be interesting for advanced users only and could be shown only when a configuration option is enabled (disabled by default). The rest of the proposal, especially #3 and #3.1, #3.2, #3.3, is less obvious. It's an interesting take. But I think this could be left alone for now, while moving forward on the two first items. Finally, as there is currently no consensus, would it be possible to implement #1 and #2 as a nautilus extension? Much like nautilus-open-terminal, knowledgeable users wanting "advanced" handling of hidden files could install the extension, and it would serve as a proof of concept and testing ground to check if it makes sense for the general public. I took a look at nautilus-python, but it's an unstable and poorly documented binding and I'm not much of a developer.
> "*" and "*.*" could be black-listed (ignore when specified by user), thus preventing the major head-ache over users mis-configuring this. ?*. ??*. A list of all [a*,b*....Z*]. I could go at this for /days/. You'll spend more time trying to prevent misconfigurations than anyone will ever configuring this key legitimately in the lifetime of its existence.
I’m not sure what your "?*" and "??*" refer to. Or why "a*" should be blacklisted. If users want to hide all files starting with "a" or "Z" or "¥" or whatever, that's their call. If the concern is that casual users who don't know how to write a simple filename pattern (with * as the only wildcard) will end up hiding stuff without realizing it, I think the solution is not "reject this feature request" but "make it a gconf setting". Nautilus already uses gconf for settings that some advanced users may want to get to, while shielding casual users from such complexity. These semi-hidden settings are also an interesting tool for distributions trying to make a few usability tweaks.
Florent: exactly my thoughts. Let's make it a gconf setting. Also even if somebody does enter a "*" as a pattern, it's hardly disastrous to have to tap "Ctrl+H".
It has been suggested[0] that the file "Icon^M", used by Mac OS X, should be also be hidden. [0] https://bugzilla.gnome.org/show_bug.cgi?id=702533#c8
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Files (nautilus), then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/nautilus/-/issues/ Thank you for your understanding and your help.