Unix File System : Directories, Filenames and Inode

Everything in the UNIX system is a file. That is less of an over simplification than you might think. When the first version of the system was being designed, before it even had a name, the discussions focused on the structure of a file system that would be clean and easy to use. The file system is central to the success and convenience of the UNIX system. It is one of the best exams plus the "keep it simple" philosophy, shows the power achieved by the careful implementation of a few well-chosen ideas.

To talk comfortably about commands and their interrelationships, we need a good background in the structure and outer workings of the file system. This chapter covers most of the details of using the file system - what files are, how they are represented, directories and the file system hierarchy, permissions, inodes (the system's internal record of files), and device files. Avail programming assignment help for any doubts and queries that might arise while going through the blog. Because most users of the UNIX system deal with manipulating files, there are many commands for file investigation or rearrangement; this chapter introduces the more commonly used ones.

The basics of files

A file is a sequence of bytes. (A byte is a small chunk of information, typically 8 bits long. For our purposes, a byte is equivalent to a character.) No structure is imposed on a file by the system, and no meaning is attached to its contents the meaning of the bytes depends solely on the programs that interpret the file. Furthermore, as we shall see, this is true not just of disc files but of peripheral devices as well. Magnetic tapes, mail messages, characters typed on the keyboard, line 'printer output, data flowing in pipes - each of these files is just a sequence of bytes as far as the system and the programs in it are concerned. The best way to learn about files is to play with them, so start by creating a small file:

junk is a file with 36 bytes - the 36 characters you typed while appending (except, of course, for correction of any typing mistakes). To see the file,

cat shows what the file looks like. The command od (octal dump) prints a Lesvisible representation of all the bytes of a file:

The -c option means "interpret bytes as characters." Turning on the -b option will show the bytes as octal (base 8) numbers as well:

The 7-digit numbers down the left side are positions in the file, that is, the ordinal number of the next character shown, in octal. By the way, the emphasis on octal numbers is a holdover from the PDP-11, for

which octal was the preferred notation. Hexadecimal is better suited for other machines; the -x option tells od to print in hex. Notice that there is a character after each line, with an octal value of 012. This is the ASCII newline character; it is what the system places in the input when you press the RETURN key. By a convention borrowed from C, the character representation of a newline is n, but this is only a convention used by programs like od to make it easy to read -the value stored in the file is the single byte 012.

Newline is the most common example of a special character. Other characters associated with some terminal control operation include backspace (octal value 010, printed as \b), tab (011, \t), and carriage return (0.15, \r). It is important in each case to distinguish between how the character is stored in a file and how it is interpreted in various situations. For example, when you type a backspace on your keyboard (and assuming that your erase character is backspace), the kernel interprets it to mean that you want to discard whatever character you typed previously. Both that character and the backspace disappear, but the backspace is echoed to your terminal, where it makes the cursor move one position backward. If you type the sequence (i.c., followed by a backspace), however, the kernel interprets that to mean that you want a literal backspace in your input, so the is discarded and the byte 010 winds up in your file. When the backspace is echoed on your terminal, it moves the cursor to sit on top of the \.

When you print a file that contains a backspace, the backspace is passed uninterpreted to your terminal, which again will move the cursor one position backward. When you use od to display a file that contains a backspace, it appears as a byte with value 010, or, with the -c option, as \b.

The story for tabs is much the same: on input, a tab character is echoed to your terminal and sent to the program that is reading; on output, the tab is simply sent to the terminal for interpretation there. There is a difference, though you can tell the kernel that you want it to interpret tabs for you on output; in that case, each tab that would be printed is replaced by the right number of blanks to get to the next tab stop. Tab stops are set at columns 9. 17, 25, etc. The command

causes tabs to be replaced by spaces when printed on your terminal. See stty(1). The treatment of RETURN is analogous. The kernel echoes RETURN as a carriage return and a newline, but stores only the newline in the input. On output, the newline is expanded into carriage return and newline. The UNIX system is unusual in its approach to representing control Informa on, particularly its use of newlines to terminate lines. Many systems instead provide "records," one per line, each of which contains not only your data but also a count of the number of characters in the line (and no new line). Other systems terminate each line with a carriage return and a newline because that sequence is necessary for output on most terminals. (The word "linefeed" is a synonym for newline, so this sequence is often called "CRLF." which is nearly pronounceable.)

The UNIX system does neither there are no records, no record counts, and no bytes in any file that you or your programs did not put there. A new line is expanded into a carriage return and a new line when sent to a terminal. but programs need only deal with the single newline character because that is all they see. For most purposes, this simple scheme is exactly what is wanted. When a more complicated

the structure is needed, it can easily be built on top of this; the converse, creating simplicity from complexity, is harder to achieve.

Since the end of a line is marked by a newline character, you might expect a file to be terminated by another special character, say \e for "end of the file." Looking at the output of od, though, you will see no special character at the end of the file it just stops. Rather than using a special code, the system signifies the end of a file by simply saying there is no more data in the file. The kernel keeps track of file lengths, so a program encounters end-of-file when it has processed all the bytes in a file.Programs retrieve the data in a file by a system call (a subroutine in the kernel) called read. Each time read is called, it returns the next part of a file the next line of text typed on the terminal, for example. read also says how many bytes of the file was returned, so the end of the file is assumed when a reader says "zero bytes are being returned." If there were any bytes left, read would have returned some of them. It makes sense not to represent the end of the file by a special byte value, because, as we said earlier, the meaning of the bytes depends on the interpretation of the file. But all files must end, and since all files must be accessed through reading, returning zero is an interpretation-independent way to represent the end of a file without introducing a new special character.

When a program reads from your terminal, each input line is given to the program by the kernel only when you type its newline (i.e, press RETURN). Therefore if you make a typing mistake, you can back up and correct it if you realize the mistake before you type newline. If you type newline before realizing the error, the line has been read by the system and you cannot correct it. We can see how this line-at-a-time input works using a cat. a cat normally saves up or buffers its output to write in large chunks for efficiency, but the cat -u "unbuffered" the output, so it is printed immediately as 'it is read:

cat receives each line when you press RETURN; without buffering, it prints the data as it is received. Now try something different: type some characters and then a CTL-d rather than a RETURN:

cat prints the characters out immediately. Cecil-d says, "immediately send the characters I have typed to the program that is reading from my terminal." The card itself is not sent to the program, unlike a newline. Now type a second ctl-d, with no other characters:

The shell responds with a prompt, because the cat read no characters, decided that meant end of file, and stopped. ctl-d sends whatever you have typed to the program that is reading from the terminal. If you haven't typed anything, the program will therefore read no characters, and that looks like the end of the file. That is why typing ctl-d logs you out - the shell sees no more input. Of course, Cecil-d is usually used to signal an end-of-file but, interestingly, it has a more general function.

Exercise 2-1. What happens when you type crl-d to ed? Compare this to the command

$ ed

What's in a file?

The format of a file is determined by the programs that use it; there is a wide variety of file types, perhaps because there is a wide variety of programs. But since file types are not determined by the file system, the kernel can't tell you the type of a file: it doesn't know it. The file command makes an educated guess (we'll explain how shortly):

These are four fairly typical files, all related to the editor: the directory in which it resides (/bin), the "binary" or runnable program itself (/bin/ed), the "source" or C statements that define the program (/usr/src/cmd/ed.c) and the manual page (/usr/man/man1/ed. 1).

To determine the types, file didn't pay attention to the names (although it I could have), because naming conventions are just conventions, and thus not perfectly reliable. For example, files suffixed .c are almost always C source, but there is nothing to prevent you from creating a .c file with arbitrary con tents. Instead, file reads the first few hundred bytes of a file and looks for clues to the file type. (As we will show later on, files with special system pro perties, such as directories, can be identified by asking the system, but file could identify a directory by reading it.)

Sometimes the clues are obvious. A runnable program is marked by a binary "magic number" at its beginning. od with no options dumps the file in

16-bit, or 2-byte, words and makes the magic number visible:

The octal value 410 marks a pure executable program, one for which the exe cuting code may be shared by several processes. (Specific magic numbers are system dependent.) The bit pattern represented by 410 is not ASCII text, so this value could not be created inadvertently by a program like an editor. But you could certainly create such a file by running a program of your own, and the system understands the convention that such files are program binaries.

For text files, the clues may be deeper in the file, so file looks for words like #include to identify C source, or lines beginning with a period to iden tify nroff or troff input.

You might wonder why the system doesn't track file types more carefully, so that, for example, sort is never given /bin/ed as input. One reason is to avoid foreclosing some useful computation. Although

doesn't make much sense, there are many commands that can operate on any file at all, and there's no reason to restrict their capabilities. od, wc, cp, cmp. file and many others process files regardless of their contents. But the for matless idea goes deeper than that. If, say, nroff input were distinguished from C source, the editor would be forced to make the distinction when it created a file, and probably when it read in a file for editing again. And it would certainly make it harder for us to typeset the C programs in Chapters 6 through 8!

Instead of creating distinctions, the UNIX system tries to efface them. All text consists of lines terminated by newline characters, and most programs understand this simple format. Many times while writing this book, we ran commands to create text files, processed them with commands like those listed above, and used an editor to merge them into the troff input for the book. The transcripts you see on almost every page are made by commands like

od produces text on its standard output, which can then be used anywhere text can be used. This uniformity is unusual; most systems have several file formats, even for text, and require negotiation by a program or a user to create a file of a particular type. In UNIX systems there is just one kind of file, and all that is required to access a file is its name.

The lack of file formats is an advantage overall programmers needn't worry about file types, and all the standard programs will work on any file - but there are a handful of drawbacks. Programs that sort and search and edit expect text as input: grep can't examine binary files correctly, nor can sort them, nor can any standard editor manipulate them.

There are implementation limitations with most programs that expect text as input. We tested some programs on a 30,000-byte text file containing no newlines, and surprisingly few behaved properly because most programs make unadvertised assumptions about the maximum length of a line of text (for an exception, see the BUGS section of sort(1)).

Non-text files have their place. For example, very large databases usually need extra address information for rapid access; this has to be binary for efficiency. But every file format that is not text must have its own family of support programs to do things that the standard tools could perform if the format were text. Text files may be a little less efficient in machine cycles, but this must be balanced against the cost of extra software to maintain more specialized formats. If you design a file format, you should think carefully before choosing a non-textual representation. (You should also think about making your programs robust in the face of long input lines.)

Directories and filenames

All the files you own have unambiguous names, starting with /usr/you, but if the only file you have is junk, and you type 1s, it doesn't print /usr/you/junk; the filename is printed without any prefix:

That is because each running program, that is, each process, has a current directory, and all filenames are implicitly assumed to start with the name of that directory unless they begin directly with a slash. Your login shell, and 1s, therefore have a current directory. The command PWD (print working directory) identifies the current directory:

The current directory is an attribute of a process, not a person or a program people have login directories, and processes have current directories. If a process creates a child process, the child inherits the current directory of its parent. But if the child then changes to a new directory, the parent is unsafe fected its current directory remains the same no matter what the child does.

The notion of a current directory is certainly a notational convenience because it can save a lot of typing, but its real purpose is organizational. Related files belong together in the same directory. /usr is often the top directory of the user file system. (user is abbreviated to usr in the same spirit as CMP, 1s, etc.) /usr/you are your login directory, your current directory when you first log in. /usr/src contains source for system programs, /usr/src/cmd contains source for UNIX commands, /usr/src/cmd/sh contains the source files for the shell, and so on. Whenever you embark on a new project, or whenever you have a set of related files, say a set of recipes, you could create a new directory with mkdir and put the files there.

Notice that it is simple to refer to subdirectories. pie/apple has an obvious meaning: the apple pie recipe, in directory /usr/you/recipes/pie. You could instead have put the recipe in, say, recipes/apple.pie, rather than in a subdirectory of recipes, but it seems better organized to put all the pies together, too. For example, the crust recipe could be kept in recipes/pie/crust rather than duplicated in each pie recipe. Although the file system is a powerful organizational tool, you can forget where you put a file, or even what files you've got. The obvious solution is a command or two to rummage around in directories. The 1s command is certainly helpful for finding files, but it doesn't look in sub-directories.

This piece of the file system can be shown pictorially as:

The command du (disk usage) was written to tell how much disc space is consumed by the files in a directory, including all its subdirectories.

The filenames are obvious; the numbers are the number of discs blocks-typically 512 or 1024 bytes each of storage for each file. The value for a directory indicates how many blocks are consumed by all the files in that directory and its subdirectories, including the directory itself. du has an option -a, for "all," that causes it to print out all the files in a directory. If one of those is a directory, du processes that as well:

The output of du -a can be piped through grep to look for specific files:

Recall from Chapter 1 that the name '.' is a directory entry that refers to the directory itself; it permits access to a directory without having to know the full name. du looks in a directory for files; if you don't tell it which directory, it assumes., the directory you are in now. Therefore, junk and ./junk are names for the same file.

Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. But they can't be created or written as ordinary files to preserve their sanity and the users' files, the kernel reserves to itself all control over the contents of directories.

The time has come to look at the bytes in a directory:

See the filenames buried in there? The directory format is a combination of binary and textual data. A directory consists of 16-byte chunks, the last 14 bytes of which hold the filename, padded with ASCII NULs (which have value 0), and the first two of which tell the system where the administrative information for the file resides we'll come back to that. Every directory begins with two entries.("dot") and .. ("dot-dot").

The directory is called the root of the file system. Every file in the system is in the root directory or one of its subdirectories, and the root is its parent directory.

Exercise 2-2. Given the information in this section, you should be able to understand roughly how the 1s command operates. Hint: cat. >foo; ls -f foo.

Exercise 2-3. (Harder) How does the PWD command operate? an Exercise 2-4. du was written to monitor disc usage. Using it to find files in a directory hierarchy is at best a strange idiom, and perhaps inappropriate. As an alternative, look at the manual page to find(1) and compare the two commands. In particular, compare the command du -a 1 grep... with the corresponding invocation of find. Which runs faster? Is it better to build a new tool or use a side effect of an old one?

Permissions

Every file has a set of permissions associated with it, which determine who can do what with the file. If you're so organized that you keep your love letters on the system, perhaps hierarchically arranged in a directory, you probably don't want other people to be able to read them. You could therefore change the permissions on each letter to frustrate gossip (or only on some of the letters, to encourage it), or you might just change the permissions on the directory containing the letters, and thwart snoopers that way.

But we must warn you: there is a special user on every UNIX system, called the super-user, who can read or modify any file on the system. The special login name root carries super-user privileges; it is used by system administrators when they do system maintenance. There is also a command called so that grants super-user status if you know the root password. Thus anyone who knows the super-user password can read your love letters, so don't keep sensitive material in the file system. If you need more privacy, you can change the data in a file so that even the super-user cannot read (or at least understand) it, using the crypt command (crypt(1)). Of course, even a crypt isn't perfectly secure. A super-user can change the crypt command itself, and there are cryptographic attacks on the crypt algorithm. The former requires malfeasance and the latter takes hard work, however, so crypt is in practice fairly secure. In real life, most security breaches are due to passwords that are given away or easily guessed. Occasionally, system administrative lapses make it possible for a malicious user to gain super-user permission. Security issues are discussed further in some of the papers cited in the bibliography at the end of this chapter. When you log in, you type a name and then verify that you" are that person by typing a password. The name is your login identification or login-id. But the system recognizes you by a number, called your user-id, or uid. Different login ids may have the same uid, making them indistinguishable from the system, although that is relatively rare and perhaps undesirable for security reasons. Besides a uid, you are assigned a group identification, or group id, which places you in a class of users. On many systems, all ordinary users (as opposed to those with login IDs like root) are placed in a single group called the other, but your system may be different. The file system, and therefore the UNIX system in general, determines what you can do by the

permissions granted to your uid and group-id. The file /etc/password is the password file; it contains all the login information about each user. You can discover your uid and group-id, as does the system, by looking up your name in /etc/passwd:

login-id: encrypted-password: uid: group-id: miscellany: login-directory: shell

The file is ordinary text, but the field definitions and separator are a convention agreed upon by the programs that use the information in the file. The shell field is often empty, implying that you use the default shell, /bin/sh. The miscellany field may contain anything; often, it has your name and address or phone number.

Note that your password appears here in the second field, but only in an encrypted form. Anybody can read the password file (you just did), so if your password itself were there, anyone would be able to use it to masquerade as you. When you give your password to log in, it encrypts it and compares the result against the encrypted password in /etc/passwd. If they agree, it lets you log in. The mechanism works because the encryption algorithm has the property that it's easy to go from the clear form to the encrypted form, but very hard to go backward. For example, if your password is ka-boom, it might be encrypted as gkmbCTrJ04COM, but given the latter, there's no easy way to get back to the original.

The kernel decided that you should be allowed to read /etc/passwd by looking at the permissions associated with the file. There are three kinds of permissions for each file: read (i.e., examine its contents), write (i.e., change its contents), and execute (i.e., run it as a program). Furthermore, different permissions can apply to different people. As file owner, you have one set of reading, writing, and executing permissions. Your "group" has a separate set. Everyone else has a third set.

The 1 option of 1s prints the permissions information, among other things:

These two lines may be collectively interpreted as: /etc/passwd is owned by login-id root, group adm is 5115 bytes long, was last modified on August 30 at 10:40 AM, and has one link (one name in the file system; we'll discuss links in the next section). Some versions of 1s give both owner and group in one invocation.

The string -rw-r--r-- is how 18 represents the permissions on the file. The first indicates that it is an ordinary file. If it were a directory, there would be a d there. The next three characters encode the file owner's (based on uid) read, write and execute permissions. rw- means that root (the owner) may read or write, but not execute the file. An executable file would have an x instead of a dash. The next three characters (x--) encode group permissions, in this case, so that people in group adm, presumably the system administrators, can read the file but not write or execute it. The next three (also r--) define the permissions for everyone else and the rest of the users on the system. On this machine, then, only the root can change the login information for a user, but anybody may read the file to discover the information. A plausible alternative would be for group adm to also have written permission on /etc/passwd.

The file /etc/group encodes group names and groups and defines which users are in which groups. /etc/passwd identifies only your login group; the newgrp command changes your group permissions to another group.

Anybody can say

and edit the password file, but only the root can write back the changes. You might therefore wonder how you can change your password since that involves editing the password file. The program to change passwords is called passwd; you will probably find it in /bin:

(Note that /etc/passwd is the text file containing the login information, while /bin/passwd, in a different directory, is a file containing an executable program that lets you change the password information.) The permissions here state that anyone may execute the command, but only the root can change the passwd command. But the s instead of an x in the execute field for the file owner states that, when the command is run, it is to be given the permissions corresponding to the file owner, in this case, root. Because /bin/passwd is "set-uid" to root, any user can run the passwd command to edit the password file. The set-uid bit is a simple but elegant idea that solves some security problems. For example, the author of a game program can make the program set-uid to the owner, so that it can update a score file that is otherwise protected from other users' access. But the set-uid concept is potentially dangerous. /bin/passwd has to be correct; if it were not, it could destroy system information under the root's auspices. If it had the permissions -rwarwxrwx, it could be overwritten by any user, who could therefore replace the file with a program that does anything. This is particularly serious for a set-uid program because the root has access permissions to every file on the system. (Some UNIX systems turn the set-uid bit off whenever a file is modified, to reduce the danger of a security hole.)

The set-uid bit is powerful but used primarily for a few system programs such as passwd. Let's look at a more ordinary file.

who is executable by everybody, and writable by root and the owner's group. What "executable" means is this: when you type

to the shell, it looks like a set of directories, one of which is /bin, for a file named "who." If it finds such a file, and if the file has to execute permission, the shell calls the kernel to run it. The kernel checks the permissions, and, if they are valid, runs the program. Note that a program is just a file with execute permission. In the next chapter, we will show you programs that are just text files, but that can be executed as commands because they have to execute permission set.

Directory permissions operate a little differently, but the basic idea is the same.

The -d option of 1s asks it to tell you about the directory itself, rather than its contents, and the leading d in the output signifies that '.' is indeed a directory. Anr field means that you can read the directory, so you can find out what files are in it with 1s (or od, for that matter). A w means that you can create and delete files in this directory because that requires modifying and therefore writing the directory file. 

You cannot simply write in a directory even root is forbidden to do so.

Instead, there are system calls that create and remove files, and only through them is it possible to change the contents of a directory. The permissions idea, however, still applies: the w fields tell who can use the system routines to modify the directory.

Permission to remove a file is independent of the file itself. If you have to write permission in a directory, you may remove files there, even files that are protected against writing. The rm command asks for confirmation before removing a protected file, however, to check that you want to do so one of the rare occasions that a UNIX program double-checks your intentions. (The -f flag to rm forces it to remove files without question.).

The x field in the permissions on a directory does not mean execution; it means "search." Executing permission on a directory determines whether the directory may be searched for a file. It is, therefore, possible to create a directory with mode --x for other users, implying that users may access any file that they know about in that directory, but may not run it on it or read it to see what files are there. Similarly, with directory permissions --, users can see (1s) but not use the contents of a directory. Some installations use this device to turn off /usr/games during busy hours. The chmod (change mode) command changes permissions on files.

chmod permissions filenames...

The syntax of the permissions is clumsy, however. They can be specified in two ways, either as octal numbers or by symbolic description. The octal numbers are easier to use, although the symbolic descriptions are sometimes convenient because they can specify relative changes in the permissions. It would be nice if you could say

but you cannot. The octal modes are specified by adding together a 4 for reading, 2 for writing, and 1 for executing permission. The three digits specify, as in 1s, permissions for the owner, group, and everyone else. The symbolic codes are difficult to explain; you must look in chmod(1) for a proper description. For our purposes, it is sufficient to note that turns permission on and that - turns it off. For example,

allows everyone to execute the command, and

turns off write permission for everyone, including the file's owner. Except for the usual disclaimer about super-users, only the owner of a file may change the permissions on a file, regardless of the permissions themselves. Even if somebody else allows you to write a file, the system will not allow you to change its permission bits.

If a directory is writable, however, people can remove files in it regardless of the permissions on the files themselves. If you want to make sure that you or your friends never delete files from a directory, remove write permission from it:

The temp is now gone. Notice that changing the permissions on the directory didn't change its modification date. The modification date reflects changes to the file's contents, not its modes. The permissions and dates are not stored in the file itself, but in a system, a structure called an index node, or i-node, is the subject of the next section.

Exercise 2-5. Experiment with chmod. Try different simple modes, like 0 and 1. Be careful not to damage your login directory!

Inodes

A file has several components: a name, contents, and administrative information such as permissions and modification times. The administrative information is stored in the inode (over the years, the hyphen fell out of "i-node"). along with essential system data such as how long it is, where on the disc the contents of the file are stored, and so on.

There are three times in the inode: the time that the contents of the file were last modified (written); the time that the file was last used (read or executed); and the time that the inode itself was last changed, for example, to set the permissions.

Changing the contents of a file does not affect its usage time, as reported by 18 -lu, and changing the permissions affects only the inode change time, as reported by ls -lc.

The -t option to 1s, which sorts the files according to time, by default that of the last modification, can be combined with -c or -u to report the order in which inodes were changed or files were read:

$ ls recipes

recipes are most recently used because we just looked at their contents. It is important to understand inodes, not only to appreciate the options on 1s but because in a strong sense the inodes are the files. All the directory hierarchy does is provide convenient names for files. The system's internal name for a file is its i-number: the number of the inode holding the file's information. 1s I reports the i-number in decimal:

It is the i-number that is stored in the first two bytes of a directory, before the name. od -d will dump the data in decimal by byte pairs rather than octal by bytes and thus make the i-number visible.

The first two bytes in each directory entry are the only connection between the name of a file and its contents. A filename in a directory is therefore called a link, because it links a name in the directory hierarchy to the inode, and hence to the data. The same i-number can appear in more than one directory. The rm command does not remove inodes; it removes directory entries or links. Only when the last link to a file disappears does the system remove the inode, and hence the file itself.

If the i-number in a directory entry is zero, it means that the link has been removed, but not necessarily the contents of the file there may still be a link somewhere else. You can verify that the i-number goes to zero by removing the file:

The next file created in this directory will go into the unused slot, although it will probably have a different i-number. The in-command links to an existing file, with the syntax

The purpose of a link is to give two names to the same file, often so it can appear in two different directories. On many systems, there is a link to /bin/ed called /bin/e, so that people can call the editor e. Two links to a file point to the same inode, and hence have the same i-number:

total 3

The integer printed between the permissions and the owner is the number of links to the file. Because each link just points to the inode, each link is equally important there is no difference between the first link and subsequent ones. (Notice that the total disc space computed by 18 is wrong because of double counting.)

When you change a file, access to the file by any of its names will reveal the changes, since all the links point to the same file.

After 1inktojunk is removed the link count goes back to one. As we said before, arming a file just breaks a link; the file remains until the last link is removed. In practice, of course, most files only have one link, but again we see a simple idea providing great flexibility.

A word to the hasty: once the last link to a file is gone, the data is irretrievable. Deleted files go into the incinerator, rather than the waste basket, and there is no way to call them back from the ashes. (There is a faint hope of resurrection. Most large UNIX systems have a formal backup procedure that periodically copies changed files to some safe place like magnetic tape, from which they can be retrieved. For your protection and peace of mind, you should know just how much backup is provided on your system. If there is none, watch out some mishap to the discs could be a catastrophe.)

Links to files are handy when two people wish to share a file, but sometimes you want a separate copy of a different file with the same information. You might copy a document before making extensive changes to it, for example, so you can restore the original if you decide you don't like the changes. Linking wouldn't help, because when the data changed, both links would reflect the change, or makes copies of files:

The i-numbers of junk and copy of junk are different, because they are different files, even though they currently have the same contents. It's often a good idea to change the permissions on a backup copy so it's harder to remove it accidentally.