Joel Liu's Library tagged linux →  View Popular

Hard links are created with the ln command. For example, the following would create a hard link named hlink1 to a file named file1, both in the current directory (i.e., the directory in which the user is currently working):

ln file1 hlink1

When a hard link is created, there is no obvious indication that it is any different from any other file. That is, hard links appear to be files of the same type as their target files (i.e., the files to which they are linked) when they are viewed with commands such as ls (i.e., list) and file (which is used to determine the type of any specified files). Likewise, when viewed in a GUI (graphical user interface), the icons for hard links are identical to those for their target files.

That the initial name of a file and all hard links to that file all share the same inode can be clearly seen by using the ls command with its -i (i.e., inode) option. Thus, for example, the following would show that the inode numbers of file1 and hlink1 from the above example are identical:

ls -i file1 hlink1

The rest of this section covers the scope of the kernel development process

and the kinds of frustrations that developers and their employers can

encounter there.  There are a great many reasons why kernel code should be

merged into the official ("mainline") kernel, including automatic

availability to users, community support in many forms, and the ability to

influence the direction of kernel development.  Code contributed to the

Linux kernel must be made available under a GPL-compatible license.

Section 5 talks about the process of posting patches for review.  To be

taken seriously by the development community, patches must be properly

formatted and described, and they must be sent to the right place.

Following the advice in this section should help to ensure the best

possible reception for your work.