194

Since the Unix file system predates Windows by many years, one may re-phrase the question to "why does Windows use a separate designator for each device?". A hierarchical filesystem has the advantage that any file or directory can be found as a child of the root directory. If you need to move data to a new device or a network device, the location in the ...


175

Originally, there was /bin for programs (essentially, executable binaries), and very soon /dev for device files and /lib for extra executable code loaded by programs (libraries). /usr also came in very early, first for user data, then as an extra OS area with its own bin and lib and then man containing the manual in electronic form. The source code was also ...


121

/run/user/$uid is created by pam_systemd and used for storing files used by running processes for that user. These might be things such as your keyring daemon, pulseaudio, etc. Prior to systemd, these applications typically stored their files in /tmp. They couldn't use a location in /home/$user as home directories are often mounted over network filesystems, ...


109

The forward slash / is the delimiting character which separates directories in paths in Unix-like operating systems. This character seems to have been chosen sometime in the 1970's, and according to anecdotal sources, the reasons might be related to that the predecessor to Unix, the Multics operating system, used the > character as path separator, but the ...


100

The best place to put system unit files: /etc/systemd/system Just be sure to add a target under the [Install] section, read "How does it know?" for details. UPDATE: /usr/local/lib/systemd/system is another option, read "Gray Area" for details." The best place to put user unit files: /etc/systemd/user or $HOME/.config/systemd/user ...


87

This is partly for historical reasons, and partly because it makes more sense this way. Multics Multics was the first operating system to introduce the hierarchical file system as we know it today, with directories that can contain directories. Citing “A General-Purpose File System For Secondary Storage” by R.C. Daley and P.G. Neumann: Section 2 of the ...


57

The first hierarchical file system as we know it today was designed for Multics. The design is described in “A General-Purpose File System For Secondary Storage” by R.C. Daley and P.G. Neumann. A salient characteristic of this filesystem is that a directory is a file which can be contained in a directory like any other file. The file structure forms a tree, ...


52

First, an up-front conflict-of-interest disclaimer: I am a long-time GoboLinux developer. Second, an up-front claim of domain expertise: I am a long-time GoboLinux developer. There are a few different structures in current use. GoboLinux has one, and tools like GNU Stow, Homebrew, etc, use something quite similar (primarily for user programs). NixOS also ...


43

Ah yes this is a very confusing part if you've dealt with Unixes for any length of time. There is a standard that most Unixes "try" to follow called FHS - Filesystem Hierarchy Standard. Given I primarily use Red Hat based distros I'm most familiar with their take on FHS for Fedora, CentOS, and RHEL Linux distros. But I've used Debian & BSD based distros ...


41

Usage of /var/www is confusing only at first sight. According to the FHS, web server data should go to /srv. That is the main rule. However, it also says that deciding about the structure of /srv is the sole responsibility of the local administrator! Therefore packages must not put anything into /srv, and the default document root must not be /srv, ...


41

Few reasons I can think of: In corporate environments, you can have thousands of users. If so, cron would have to scan through every single user's directory every single minute to check for the crontab file (whether it has been created, deleted, or modified). By keeping them in a single location, it doesn't have to do this intensive scan. Home directories ...


38

From "Linux Filesystem Hierarchy", section /lost+found": As was explained earlier during the overview of the FSSTND, Linux should always go through a proper shutdown. Sometimes your system might crash or a power failure might take the machine down. Either way, at the next boot, a lengthy filesystem check using fsck will be done. Fsck will go ...


38

It's actually not the "traditional" location at all. Traditionally, anything you installed after the OS went into /usr/local, and indeed that's the "Classical Apache path layout" (their words) to this day. For a long time, it was /home/httpd. What you're seeing is that an Apache that has been configured for a particular OS -- whether that's Red Hat Linux, ...


37

The "more correct" depends on your distribution. You should check your distribution's guidelines on where to put software that isn't managed by the package manager (often /usr/local) OR on how to create your own package for it. As you said TeamSpeak just put everything in one folder (and may not be easy to reorganise), yes /opt/ is probably best. (But, ...


36

There are no security concerns behind having a single directory tree. The guys who designed Unix had a bunch of experience with operating systems that required users to know what physical device contained a given resource. Since part of the purpose of an operating system is to create an abstract machine on top of real hardware, they thought it much simpler ...


34

As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages. The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" ...


33

From man wget: -x, --force-directories: [...] create a hierarchy of directories, even if one would not have been created otherwise. E.g. wget -x http://fly.srk.fer.hr/robots.txt will save the downloaded file to fly.srk.fer.hr/robots.txt.


32

On linking You generally do not link /usr/local/* with /bin, but this is more of a historical practice. In general, there are a few "technical" reason why you cannot do what you're suggesting. Making links to executables in /bin can cause problems: Probably the biggest caveat would be if you're system is having packages managed by some sort of package ...


32

The .. entry in the root directory is a special case. From the POSIX standard (4.13 Pathname Resolution, where the . and .. entries are referred to as "dot" and "dot-dot" repsectively): The special filename dot shall refer to the directory specified by its predecessor. The special filename dot-dot shall refer to the parent directory of its predecessor ...


30

In my opinion, the right place is /srv/movies-enthusiast. A "service" does not have to be a daemon or program, it just has to be a service that the system provides (such as being able to get your movies there). Here's a quote from the FHS: /srv contains site-specific data which is served by this system. I definitely think your usage falls under that ...


30

The core dump is written in the current directory of the process at the time of the crash. Of course core dumps need to be enabled, by default those are usually disabled. Check the output of ulimit -c, if that's 0 then no core file will be written. Run ulimit -c unlimited to enable core dumps; this is a per-process setting which is inherited by processes ...


30

You can't, given the user creating the directory has sufficient permission to write on the parent directory. You can instead leverage the inotify family of system calls provided by the Linux kernel, to watch for the creation (and optionally mv-ing) of directory shop in the given directory, if created (or optionally mv-ed), rm the directory. The userspace ...


30

To answer literally based on the question of preventing a folder of a certain name to be created. touch shop You can't create a directory if a file with a identical name existing mkdir: cannot create directory ‘shop’: File exists


28

Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system. A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the ...


28

From the Wikipedia page on the Filesystem Hierarchy Standard: Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, following the FHS version 3.0. According to the FHS version 2.3, this data should be stored in /var/run but this was a problem in some cases because this directory isn't ...


25

While I agree with akond's answer, I think there is a more important aspect to it. Most of the other locations (such as /usr/local) are typically managed by the system (the package manager). /var is usually where files go that are not managed by the package manager (system wide 'data'). I also think the definition from the FHS is a bit more accurate (the ...


25

This change was introduced by BSD after 1985 (BSD 4.2 was still documenting /usr) and in or before 1988 (BSD 4.3/SunOS 4.1 hier(7) manual page already documents /home). It was quickly followed by Solaris 2.0 (which kind of merged System V and BSD) and was later adopted by most other Unix vendors. This is from the Solaris 2.0 useradd manual page: -D ...


25

Systems using systemd are usually configured to dump cores to /var/lib/systemd/coredump/ You may use the coredumpctl command to list core dumps. See also no-more-coredumps-after-migrating-to-systemd


25

I recommend visiting the Filesystem Hierarchy Standard. /media is mount point for removable media. In other words, where system mounts removable media. This directory contains sub-directories used for mounting removable media such as CD-ROMs, floppy disks, etc. /mnt is for temporary mounting. In other words, where user can mount things. This directory is ...


Only top voted, non community-wiki answers of a minimum length are eligible