After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 311010 - better handling of hidden and backup files
better handling of hidden and backup files
Product: nautilus
Classification: Core
Component: general
Other All
: High enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 138440 315465 (view as bug list)
Depends on:
Reported: 2005-07-20 14:25 UTC by Stanislav Brabec
Modified: 2021-06-18 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Simple patch to hide files by glob pattern (4.33 KB, patch)
2009-05-10 11:10 UTC, Stephen Kennedy
needs-work Details | Review

Description Stanislav Brabec 2005-07-20 14:25:52 UTC
Nautilus has invisible files feature (.hidden, .* *~), but it complicates some

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

5. CD burning - report about invisible files or show them by default.
Comment 1 Luke Hutchison 2005-07-20 17:16:44 UTC
There should also be a way of opening the backup file, perhaps by right-clicking
and then going "Open backup version with...".
Comment 2 Luke Hutchison 2005-07-20 17:18:47 UTC
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.
Comment 3 Luke Hutchison 2005-07-20 17:20:09 UTC
*** Bug 138440 has been marked as a duplicate of this bug. ***
Comment 4 Luke Hutchison 2005-07-20 17:21:58 UTC
Also see bug 138440 for info on handling of duplicate backup file names when
moved to trash.

Comment 5 Christian Neumair 2005-09-14 22:28:33 UTC
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.
Comment 6 Christian Neumair 2005-09-14 22:30:05 UTC
*** Bug 315465 has been marked as a duplicate of this bug. ***
Comment 7 Christian Neumair 2005-10-03 12:29:24 UTC
Mass changing Nautilus version for bugs that have GNOME 2.13 version info.
Comment 8 bi2h5da02 2007-11-20 02:14:40 UTC
(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...
Comment 9 bi2h5da02 2008-08-31 19:07:48 UTC
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?
Comment 10 Stephen Kennedy 2009-05-10 11:10:53 UTC
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.
Comment 11 daniel 2009-06-17 19:56:40 UTC
I tried out the patch by Stephen Kennedy and it is working great.  What needs to occur before this can be integrated into nautilus?
Comment 12 Stephen Kennedy 2009-08-06 20:59:17 UTC
Changed version, I think it's still applicable.
Comment 13 A. Walton 2009-09-28 14:26:33 UTC
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.
Comment 14 Stephen Kennedy 2009-12-24 15:06:01 UTC
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?
Comment 15 A. Walton 2009-12-24 21:42:34 UTC
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.
Comment 16 Florent V. 2010-01-24 08:50:46 UTC
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.
Comment 17 A. Walton 2010-01-24 19:19:39 UTC
> "*" 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.
Comment 18 Florent V. 2010-01-24 19:59:30 UTC
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.
Comment 19 Stephen Kennedy 2010-09-29 21:20:37 UTC
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".
Comment 20 António Fernandes 2013-06-20 16:24:13 UTC
It has been suggested[0] that the file "Icon^M", used by Mac OS X, should be also be hidden.

Comment 21 André Klapper 2021-06-18 15:29:31 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
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
and create a new ticket at

Thank you for your understanding and your help.