https://linux-audit.com/linux-history-how-dot-files-became-hidden-files/ Search for:[ ] Linux Audit The Linux security blog about Auditing, Hardening, and Compliance * Twitter * RSS * Home * Linux Security * Lynis * About 2016-05-30 (last updated at April 30th, 2017) Michael BoelenFile System Leave a comment Linux History: How Dot Files Became Hidden Files The history of hidden files Ever wondered why there are files on your Linux system, starting with a dot? The short answer: they are shortcuts. The story begins many years ago when the first file systems were created on UNIX. To allow easy navigation, a single file with a dot (.) was added to each directory. Secondly, a double dot file (..) was added to easily move up in the directory structure. As these files had no real data in them, a quick hack was added to the ls binary. The "hack" The change made to the ls binary involved checking for the first character. If that was a dot, it should be ignored. And it worked great! Something which was not anticipated is what we now know as a hidden file. If you create a file starting with a dot, it will become a file on disk, but which is not displayed by default. This behavior is the result of the earlier hack applied to the ls binary. Screenshot of ls showing hidden files Big difference when seeing all files Are Hidden Files Bad? So with all these hidden files, we might wonder if their purpose is good or bad. After all, it can declutter your home directory, by showing less files. While this is true, the opposite is true as well. Most utilities create hidden files, and might not really clean things up when unneeded. With utilities scanning your home directory, things slowly will cost more and more time. More Details In a Google+ post by Rob Pike, A lesson in shortcuts, the more detailed rationale behind the dot files. Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on). When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this: if (name[0] == '.') continue; This statement was a little shorter than what it should have been, which is if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue; But hey, it was easy. Two things resulted. First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted. Second, and much worse, the idea of a "hidden" or "dot" file was created. As a consequence, more lazy programmers started dropping files into everyone's home directory. I don't have all that much stuff installed on the machine I'm using to type this, but my home directory has about a hundred dot files and I don't even know what most of them are or whether they're still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge. I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake. So what do you think? Are dot files evil or good? * Facebook * Twitter * Buffer * dot files * hidden files * ls One more thing... Keep learning So you are interested in Linux security? Join the Linux Security Expert training program, a practical and lab-based training ground. For those who want to become (or stay) a Linux security expert. See training package --------------------------------------------------------------------- Lynis Enterprise screenshot to help with system hardeningSecurity scanning with Lynis and Lynis Enterprise Run automated security scans and increase your defenses. Lynis is an open source security tool to perform in-depth audits. It helps with system hardening, vulnerability discovery, and compliance. Download Post navigation << The Difference Between Auditing and Vulnerability Scanning The Most Influential Linux Security Blogs >> Continue reading No related posts found. Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment[ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. About Linux Audit CISOfy icon small This blog is part of our mission: help individuals and companies, to scan and secure their systems. We simply love Linux security, system hardening, and questions regarding compliance. Besides the blog, we have our security auditing tool Lynis. Open source, GPL, and free to use. Lynis project page For those with enterprise needs, or want to audit multiple systems, there is an Enterprise version. "One security solution to audit, harden, and secure your Linux/UNIX systems." Benefits: * Perform audits within a few minutes * Central management * Powerful reporting * Compliance checks (e.g. PCI DSS) * Additional plugins and more tests Lynis Enterprise screenshot Learn More Enjoy the articles! Linux and UNIX security automation Lynis is a free and open source security scanner. It helps with testing the defenses of your Linux, macOS, and Unix systems. Typical use-cases for this software include system hardening, vulnerability scanning, and checking compliance with security standards (PCI-DSS, ISO27001, etc). Download Recent Posts * Major release: Lynis 3.x * The 101 of ELF files on Linux: Understanding and Analysis * How to promote your open source project * OpenSSH security and hardening * Livepatch: Linux kernel updates without rebooting * How to secure a Linux system Contact This blog is part of our mission to share valuable tips about Linux security. We are reachable via @linuxaudit Company details CISOfy De Klok 28, 5251 DN, Vlijmen, The Netherlands +31-20-2260055 Website: https://cisofy.com * Twitter * RSS A Linux security blog about system auditing, server hardening, and compliance.