This term is a wonderful demonstration of Unix at large being an organically grown system that was shaped and moulded as its users' habits built upon each other. It is the colloquial name for a file that stores some of a user's settings or preferences for a specific application or a class thereof. The name derives from the fact that they're commonly stored in a file or directory whose name starts with a dot, located directly under the user's home directory. This became a convention because of the larger convention that filenames starting with a dot be treated as hidden, although there's nothing actually special about them. This was originally a simple heuristic to avoid having the special . and .. directories show up in every file listing.

Examples of DotFiles can be seen in SampleConfigFiles.

Unfortunately, dotfiles have led to the chronic phenomenon of dotfile clutter. Do an ls -lA on a typical user’s home directory, and you will likely see dozens of names beginning with dots. This has a few unfortunate effects:

• Lack of privacy. If the user wants to make some files readable to other users on the machine, those files have to be put in a directory which is readable by those other users. But in order to access that directory, its parent directory also has to be readable by those users. And its parent, as appropriate, and so on right up the user’s home directory—the one containing all these dotfiles. So other users can at least see the names of those dotfiles, if not their contents, and thereby deduce what applications it’s likely you’re using. And it’s surprising how many of these items are created world-readable, so other users can see their contents.

  Other users need execute permission to traverse a directory, but they don't need read permission for it. Of course DotFiles by and large have guessable names, so if you can traverse a user's home directory you can read their DotFiles by blindly trying names like .bashrc. But note also that almost all of these files can be chmodded to non-world-readable with no drawbacks. In other words, this is near as big a concern as the above paragraph makes it out to be. —AristotlePagaltzis

  Assuming you remember to do that. Which still doesn’t change the fact that knowing those files exist already gives information away. –LawrenceDoliveiro

  You mean: Other users need read permission to list the names of items in a directory and execute permission to actually access those items. –LawrenceDoliveiro

  No. I meant exactly what I wrote, and it is correct. To access /home/ap/www/index.html, you need to traverse the root directory, home, ap and www, in order to get to index.html, so you need execute permission on each of those directories, but need read permission only on the file. —AristotlePagaltzis

• Untidiness. Anything the user wants to create, has to be found by starting from the top level of their home directory. So at this top level, you have a whole bunch of items mixed together, some created explicitly by the user, others implicitly by apps run by the user. Yes, directory-listing utilities commonly offer the option to hide dotfiles and just show the others, but the opposite option seems a little harder to achieve.

For these reasons, it seems a good idea to give the user more control over where these preference files are created. The only serious proposal I know of is the XDG Base Directory Specification. This says that user prefs should be created in the directory specified by the EnvironmentVariable XDG_CONFIG_HOME. If this is not defined, then the prefs should go in the directory $HOME/.config/. The directory should be created if it doesn’t exist, to be readable and writable by the owner but inaccessible to anyone else.

Thus, all the dotfile clutter is replaced by a single dotted-directory name, and the user has the option of overriding even this.