Whats does the symbol -> indicate in linux and how about hard and symbolic links
 

what does the symbol -> indicate in linux. For an instance i saw /etc/named.conf -> /var/named/chroot/etc/named.conf. is dat a symbolic link


If it is, then in a new machine,i have the file /etc/named.conf. How to i make it point to /var/named/chroot/etc/named.conf?

Hi Sarah,

Yes, that indicates a symbolic link. So when you use /etc/named.conf you're actually using /var/named/chroot/etc/named.conf

But form the path, it looks like this is comming from a rescue system, aren't you? (named.conf should be in /etc in the first place). If for some strange reason you want to use named.conf from the /var/named/chroot/etc directory you can try
This will create a symbolic link in /var/named/chroot/etc to /etc/named.conf.

Regards,
Louis

A bit more information:

A symbolic link is a small file that contains a path specification to a file or directory (which may not exist). The file is marked "special" as a symbolic link, just like directories are marked special (both use different bits in the "mode" field of the inode.

A hard link, on the other hand, is not special. The native linux filesystems allow inodes to have multiple names - each name represents a hard link. The number of hard links is maintained by the "links" field of the inode.

A file cannot be deleted until the link count goes to zero. Now that said, a file may still be delayed in deletion - when a file is opened, the inode is copied into memory. The disk file may then be deleted, and if that is the last remaining hard link, is ready for deletion... except for the open file which maintains the inode in memory. If a system crash prevents the file from being deleted, a repair pass over the filesystem (either fsck, or more likely a journal pass) will identify the file as missing, and recreate a name (fsck puts it in the filesystems lost+found directory) or restore the file name that was deleted from the journal.

The link count is also what makes it hard to delete directories. There are two reasons for that, 1 - it is a special file, so it has special handling... 2 - there are always two links in a directory: "." which is a hard link to the directory inode itself, and ".." which is a hard link to the parent directory. Removing one link is easy, but removing two causes race conditions (hence the special handling). A partially deleted diretory is a filesystem corruption - it can cause a number of problems - pointing to unused/deallocated/deleted inodes, or pointing to non-existent parent directories... Even the pointer to self would prevent normal cleanup, as an existing hard link would indicate a used file... yet that same file (a directory) is not accessable through the filesystem - thus a "lost" file.

There are some significant differences between hard and soft links- a hard link can only exist within a single filesystem. They cannot cross filesystems (after all, the link count is only on one inode). A symbolic link, being symbolic, can point to any file name with the system, which allows it to point to files on other filesystems. This is also why the pointed to file may not exist - it could have been deleted, or the file system it is on is not currently mounted.

Now, an inode is nothing more than a chunk of data that describes the allocations for data (the contents of a file). The combination of inode + data allocations is the file. The inode number can be thought of as just an index into an array of inodes stored on disk. Sometimes the array is stored as a sparse array (containing holes), but that is up to the specific filesystem design (XFS is one that does this). A directory is just a file that contains inode numbers and the associated name (minimally - some filesystems store additional information to make directory access faster). It is not possible to open file without an inode (one will be created if the option to create is provided, otherwise you get a "file not found" error).

Well thank u both of you....

Lpwevers,i did try and did like the way u wrote it there but unlike the existing server where in the /etc/ directory where "/etc/named.conf -> /var/named/chroot" been shown,doing what u said created vice versa that is in the /var/named/chroot/etc , "/var/named/chroot/etc/named.conf -> /etc/named.conf" is been shown. n doing the vice-versa of the command says /etc/named.conf exists.

thats because "->" this shows reference of the file 2nd to 1st, so in this case of named the original file lies in /etc/named.conf and is referenced to 'chroot' inside the /var dir

Hope that makes the concept of reference clear.

Leave the link the way it was originally. When you have the "bind-chroot" package installed, the named process is confined, for security, inside the chroot directory and cannot access anything outside it. That chroot directory is what the named process will see as its root directory (/), so the link "/var/named/chroot/etc/named.conf -> /etc/named.conf" would actually be pointing to itself.

The actual config file is stored inside the chroot. The link "/etc/named.conf -> /var/named/chroot/etc/named.conf" is needed so that administrative tools, running outside the chroot, can access that config file via its usual path in /etc.