Re: Hidden files
On Wed, Jun 07, 2006 at 12:02:23AM +0100, Roger Leigh wrote:
> Ron Johnson <ron.l.johnson@cox.net> writes:
> > Just as /etc/bashrc is not hidden, whereas ~/.bashrc is, *why*
> > should any *system* files be hidden?
>
> IMO dotfiles are a historical artifact which we are stuck with. If we
> were just starting today, I'm sure we would be using ~/etc/bashrc
> rather than ~/.bashrc so the user's files match the standard
> locations. It's logical, simple, and would make many things easier.
This argument is valid only for configuration. There are more
reasons to have files which are not displayed unless you ask for
them. For example:
* .svn
Storing this metadata somewhere else would mean you have to
explicitely purge it every time you do something as basic as
deleting a dir. Also, you are no longer free to move things around
by hand, can't move them to another machine without some kind of
export/import, and so on, so on.
* .xvpics
It takes a long time to show the thumbnails, so caching them is not
a bad idea. However, if this cache was placed anywhere else than
the dir which contains the images, thumbnails would accumulate
indefinitely -- with .xvpics, deleting the directory removes the
relevant cache without any extra effort.
> While historical reasons are acceptable for users' dotfiles, I remain
> to be convinced that there is a logical rationale for them in any
> system location, or even anywhere under $HOME except the root.
Showing dotfiles by default doesn't provide you with any extra
security. The rootkit can as easily use /var/lib/dpkg/info/ or even
/mnt/win/Windows/System32/hidden\ from\ mom/pr0n/. Also, unlike Sony's
rootkit, dotfiles are hidden only from tools that explicitely remove them
from the output -- that is, ls, mc or nautilus but not find.
Dotfiles are just a means of hiding visual spam. The less irrelevant
information is forced into your eyes, the more attention you have left for
real work. And " -a" is just three keystrokes anyway.
On the other hand, the issue which started this thread _is_ valid IMHO.
/usr/lib/xulrunner/.autoreg is not "metadata you're not going to look for"
but a file that is not really different from, let's say, no_ppp_on_boot.
A marker that is a functional part of xulrunner and that is usually
important to those who bother to take a look at the relevant dir.
Note that I think you're right because of semantics, not because of broken
"security" scanners.
Regards,
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: