Non-Linux hidden files like Thumbs.db should be treated the same as .filename

Bug #130997 reported by Endolith
58
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Nautilus
Confirmed
Wishlist
Baltix
Invalid
Undecided
Unassigned
nautilus (Ubuntu)
Triaged
Wishlist
Ubuntu Desktop Bugs
nemo (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: nautilus

When a file is named .something in Linux, it's considered a hidden file, and Nautilus can be toggled to display these or not.

I guess OS X uses the same convention, so .DS_Store and the like will not be shown?

But other OSes don't, so we have things like Thumbs.db, desktop.ini, and so on. These should be treated exactly the same way by Nautilus; hidden from view until you toggle the "Show hidden files" option. Either by setting a blacklist of common filenames or by actually reading the hidden file attribute from NTFS/FAT/whatever.

Revision history for this message
Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug is known upstream, the address is: http://bugzilla.gnome.org/show_bug.cgi?id=311010 ; please feel free to post your comments there too, thanks a lot.

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
status: New → Triaged
Changed in nautilus:
status: Unknown → Confirmed
Revision history for this message
Endolith (endolith) wrote :

Is there a way to read the "hidden" attribute from filesystems like FAT and NTFS that support it?

Revision history for this message
Endolith (endolith) wrote :

Found a thread about it: http://thread.gmane.org/gmane.comp.gnome.nautilus/12197

Seems like this needs to be added to the kernel drivers to request the hidden attribute.

Revision history for this message
Endolith (endolith) wrote :

And another thread on the kernel list:

http://www.spinics.net/lists/linux-fsdevel/msg17861.html

How do we mark this bug as affecting the kernel?

Revision history for this message
dfalk (dfalk) wrote :

Here is a patch that will allow the patterns that are hidden to be changed in gconf.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you add your change to the upstream bug?

Revision history for this message
dfalk (dfalk) wrote :

It's on the upstream bug; it has gone ignored for a while though. I submitted it to the nautilus mailing list as well and once again received no response at all.

Revision history for this message
dfalk (dfalk) wrote :

Could this patch please be applied to the downstream nautilus? I don't know of any other way to get it applied upstream. Perhaps this way it could eventually work its way into upstream nautilus?

Revision history for this message
Marcus Carlson (0-launchpad-mejlamej-nu) wrote :

Hmm, seems the kernel devs where not so happy about the idea. If we really want this it should be done in gvfs (with filesystem specific checks) and not in nautilus, definitely not with blacklists.

Revision history for this message
dfalk (dfalk) wrote :

So does this mean that nothing will be done at all?

Besides, I can think of cases beyond Thumbs.db, where it would be nice to have a way of hiding files. Pesky .pyc files are a good example. Nautilus already does its own hiding of files, such as files ending with ~, so why is this a big problem?

Also, sometimes folders will get copied from one filesystem to another, and so hiding Thumbs.db on a filesystem that looks like Windows, only to have it appear on an ext4 partition after copying, doesn't seem like a much better solution. Of course I'm not sure if that's what the "filesystem specific checks" would imply, but it's a potential problem.

Revision history for this message
Marcus Carlson (0-launchpad-mejlamej-nu) wrote :

gvfs could add custom layer to hide files using the "standard" .hidden file in each directory.

Revision history for this message
Endolith (endolith) wrote :

Remember there are two possibilities:

1. Reading the hidden attribute from filesystems that support it
2. Pattern-matching on commonly-hidden filenames like Thumbs.db, desktop.ini, ~*.tmp, __MACOSX, etc. - like a global .hidden file

The kernel devs refuse to consider #1, while dfalk's patch seems to implement #2.

Does Samba do something like #1 that could be implemented for local filesystems?

I don't see anything on http://bugzilla.kernel.org/ about this. The mailing list discussion says it will be ignored, but maybe we should file it anyway?

I don't think #2 is a bad idea at all, though, and could probably be extended to be part of a related idea to allow for files to be "attached" to other files, with the attachments hidden by default (book.txt~ attached to book.txt, and web_page_files attached to web_page.html, for instance). That might require glob-matching as well as filename matching, though, but it's also something done on a file-level rather than a filesystem-level.

Does the .hidden convention allow for any type of wildcard or regexp? I can't find documentation.

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for your work, unsetting the patch status though since that require extra upstream discussion and nautilus might not be the right component to change there either since the fileselector etc have similar issue

Revision history for this message
mati (mati-wroc) wrote :

Solution #1 wouldn't work for hiding python .pyc files - so it might be good to go with patching nautilus (and gtk+ file opener?).

Changed in nautilus:
importance: Unknown → Wishlist
Revision history for this message
Thomas Hotz (thotz-deactivatedaccount) wrote :

I like this bug. Good idea!

Changed in baltix:
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nemo (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.