Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

The output of ls -l command yields the following result:

enter image description here

What is the number field between file permission and owner? i.e. what are those 1, 1, 1, and 2? I checked the --help but that doesn't explain it.

[EDIT] I thought it was the number of files in a directory but it isn't. See image. "tempFolder" has 3 files but still show a "2"

share|improve this question
add comment

2 Answers

up vote 12 down vote accepted

Note: edited after @StephaneChazelas comment

The first number of the ls -l output after the permission block is the number of hard links.

It is the same value as the one returned by the stat command in "Links".

This number is the hardlink count of the file, when referring to a file, or the number of contained directory entries, when referring to a directory.

A file typically has a hard link count of 1 but this changes if hard links are made with the ln command. See the Debian Reference manual.

In your example, adding a hard link for tempFile2 will increase its link count:

ln -l
ln tempFile2 tempHardLink
ln -l

Both tempFile2 and tempHardLink will have a link count of 2.

If you do the same exercize with a symbolic link (ln -s tempFile2 tempSymLink), the count value will not increase.

A directory will have a minimum count of 2 for '.' (link to itself) and for the entry in its parent's directory .

In your example, if you want to increase the link count of tempFolder, create a new directory and the number will go up.

ls -l tempFolder
mkdir tempFolder/anotherFolder
ls -l tempFolder

The link from anotherFolder/ to tempFolder/ (which is ..) will be added to the count.

share|improve this answer
    
that's what I though so so I create more files inside a directory (e.g. tempFolder) but it still shows "2" –  KMC Jul 14 '12 at 10:58
    
I didn't down vote but whoever did should leave a comment –  KMC Jul 14 '12 at 11:04
    
You are right @KMC, my first answer did not make sense and did not match what you see on the console. I'll try to elaborate. –  Damien Jul 14 '12 at 11:08
2  
See: unix.stackexchange.com/questions/31073/… –  Mat Jul 14 '12 at 12:24
2  
@EmanuelBerg when file systems were far less reliable than they are now and you were working on the file system you developed, and ls could spend 2 characters and give you more information, and there was no stat(1) command nor find(1) nor fsck, nor symlinks it was probably far more useful than it is today. It can't be changed without breaking shell scripts whose writers have long past into /dev/null; It has been that way since at least 1979. –  msw May 12 '13 at 11:31
show 5 more comments

On Unix, typically, a file is some entry in a table of files. There are different sorts of files: regular files, devices, symbolik links, doors, pipes, sockets, directories...

The inode number (which you can see in the output of ls -i) is the index in that table.

Now, you don't access files by inode but by path. A path is a chain of directory entries. You'll notice we're not talking of folder but of directory here. Because it is what a directory is (think of a phone directory).

A directory is a special kind of file that gives names to a number of inodes. A directory entry is a mapping from a name to an inode.

A given file (an inode) can have more than one name in one directory (just like there can be more than one name at a phone number), and can also have names (entries) in more than one directory. Those are called links also known as hard links to distinguish with soft links (a special type of file which is a pointer to a path).

A file (inode) keeps track of the number of links (of entries in any directory) that it has, so that when the number reaches 0 (when it is being unlinked from the last directory it was referenced in), it is deallocated.

That's that number (the number of links) that is displayed in the ls -l output.

When a non-directory file is created the first time (with the open or creat (or bind or mknod for some types of files) system calls), it is done by providing with a path to the new file (like "/a/b"). What happens then is a new file and inode is allocated and a new entry is added to the directory associated with the "a" name in the "/" root directory. That's the initial link so the link count is one.

More links can be added later on with the link() system call (the ln command). And links can be removed with the unlink() system call (the rm command).

You'll notice that the files of type directory generally have a number of links greater or equal to 2.

Now, when you create a directory, you're calling the mkdir() system call. Something like mkdir("/a/b"). What it does then is allocate a new file of type directory. In that new directory, it automatically creates two entries:

  • "." (dot for directory). Which is a link to itself. So the link count is now 1.
  • ".." (for directory's directory). Which is a link to "/a". So the link count of "/a" is incremented by one

Then that new directory is linked to "/a" (an entry is added in "/a" for it), so its link count is now 2. If a "/a/b/c" directory is created, because of the ".." entry in "/a/b/c", the link count of "/a/b" will become 3.

Most Unices restrict creating further links to a directory because they can cause problematic loops. When they do allow a link() on a directory, generally only the superuser can do it.

Some filesystems like btrfs depart from that traditional directory structure. You'll notice that link counts on directories in btrfs file systems are always one even though those directories do contain a "." entry with the same inode number as themselves in them.

The fact that the link count is traditionally 2 plus the number of subdirs has its use. For instance, in:

find . -name '*.c' -print

If . does not contain subdirs but contains millions of files. By checking the link count of ., find can know that there is no subdir. So all find has to do is read the content of the directory and report the entries that end in .c (like a grep '\.c$' on a few megabyte file, no big deal). Otherwise, find would have to check the type of every single file to see if there are directories to descend into in there (resulting in as man lstat() system calls). Of course, this kind of optimisation doesn't work on btrfs.

share|improve this answer
    
+1, great answer :) By looking at the ls source code, I noticed that the link number was updated after a call to stat. So the stat command will give you the value of links for a file or directory. –  Damien May 12 '13 at 8:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.