Hi everybody .
I am a newbie in UNIX.
I understood the concept of unix system files .
For normal files , the link field is the number of hard links that points to this file.
But there is no hard links for directories so what is the meaning of link field tor those directories?
Thanks
Directories do have hard links. Directories are required to contain a subdirectory called "." which is a link to itself. A directory may also contain a subdirectory. If it does, the subdirectory is required to contain, well, a "subdirectory" called ".." which is actually a link to the parent. Example:
$ mkdir -p a/b/c
$ ls -id a/b a/b/. a/b/c/..
30768 a/b 30768 a/b/. 30768 a/b/c/..
So a/b and a/b/. and a/b/c/.. are all the same directory.
so the link field is the number of hard links that is the number of directories that points on it?
No, the number of links is the number of links. You seem to understand that if I do:
touch file1
ln file1 file2
that I have one file with 2 links. Now extend that to directories. In the example I show above, a/b and a/b/. and a/b/c/.. are not three directories. They are three hard links to one directory.
I am a little confused.
I got labs to prepare and the question is
I would answer , the same than for normal files ..
But anyway , I understood what you said .
Well first, it seems you breaking the rules which state:
(6) Do not post classroom or homework problems.
But this is either a trick question, or a case of ignorance on the part of the person who prepared the lab. So I am going to bend the rules a bit, and explain further.
To say "Normal links cannot be done on directories." comes close to be being true but it doesn't make it all the way. The link() system call usually will work on directories, but only for root. The Posix Standard says: "If path1 names a directory, link() shall fail unless the process has appropriate privileges and the implementation supports using link() on directories." So a Posix compliant OS may or may not choose to allow root to perform the operation, but it must prohibit ordinary users from linking to directories. In my opinion, the only valid reason that root would have to do this would be to restore a missing . or .. entry thus repairing some filesystem damage.
In the old days, mkdir was a suid executable which used the mknod() system call to create the requested directory and then immediately did 2 link() calls to populate it with the needed . and .. links. Later the mkdir() system call was born and now it should be used to create directories. It does all three operations atomically so the directory never appears to be in an invalid state to other programs. So it is now very rare and very unusual to perform a link() on a directory. And your OS may even prohibit it.
But every OS allows mkdir() and this system call is more or less required to create . and .. entries each directory that it makes. What is explicitly required is that opening . and .. will behave as if those links were present. That is, opening . must open the directory that contains it. And opening .. must open the parent directory. A link is a link whether it was made by link() or mkdir(). I could use mkdir() to create a normal directory. On at least some versions of Unix, I could then use unlink() to remove .. and then restore it via link(). Assuming I get it right, you could not examine the resulting directory to see if I did that or not. And many versions of Unix supply root-only commands called link and unlink that should be able to pull this off. I'm not going to test this though... I think it is very dangerous to fiddle around with a filesystem like this.
So I really must argue that a statement like "Normal links cannot be done on directories." is, at best, carelessly phrased.