Unix FAQ

Good

This page has received an average rating of 84% from 16 readers

Filenames

Unix filenames are case sensitive - a directory can contain two files named 'sometext' and 'SomeText' - they are different files (unless one is a link to the other ).

Any character is legal in a filename. Filenames can, and do start with a '.' (so called 'hidden files). Characters that are out-lawed in filenames on other systems, such as '$' and '!' are perfectly valid in a unix filename. Even characters that have special meaning to the shell are legal. I suggest you avoid using such characters until you master the '-inum' and '-exec rm ..' options on the find(1) command.

Filename lengths are variable within Unix directories, there are no '8.3' type restrictions. Exactly how long a filename can be varies with different versions, but if it's less than 255 characters then you probably should be upgrading your system...

BTW The only thing hidden about a 'Hidden File' is that it does not appear on a ls directory listing - until you add the '-a' option to your ls command...

File types and extensions.

Unix files are not typed in the same way you might have seen under other operating systems. Under systems such as VMS or DOS the file extension is a critical part of the information about a file - executable programs are always '.EXE' or '.COM' for example. Under Dos if you change the extension of a executable you can no longer run it.

Unix file extensions have no such special meaning. An executable could have the extension '.splat' and still be run. In fact the period '.' in the file name has no special meaning at all and is just another character in the file name. A perfectly valid filename could be 'just.another.file.name'.

Unix files do have types but only a very small number; Plain files, directories, symbolic links, device files, to name the more common ones. 'Plain file' encompasses most of files you are likely to encounter, and includes executables, text files, spreadsheets, configuration files, scripts, etc, etc...

Files often have what is known as a Magic number.This is an identifying sequence at the start of the file which determines its type. The command file(1) uses the magic number to print a meaningful description of a file, it uses the file /etc/magic as a reference;
sun% file /bin/ls
/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped

In this example '/bin/ls' ( the program that lists directories) is identified as a Sparc executable.

Directories

Under most operating systems the directory holds all the key information about a file - such as it's name, size, location, access and modification times, any ownerships, permissions, etc, etc. A Unix directory contains just two things - a filename and an 'Inode' number. ..

The Inode

The Inode is a pivitol structure within the Unix filesystem. The purposes of an inode is to hold all the information about a file you would normally expect to see in a directory entry on another system - file size, location, access & modification times, ownership, etc. To exist in a filesystem every file must have a inode. Directories, symbolic links, device files and pipes all have inodes.

An inode has a Link Count. The link count is simply the number of directories entries pointing to it. Yes, one file can have more than one directory entry, see Hard Links for more information on that. The link count is shown on an ls -l' output - it's the number sandwiched between the permissions and the file owner, this file is inode #60 and has 5 directory entries pointing to it.
sun (ksh) % ls -li utmpd
60 -rwxr--r-- 5 root sys 597 Sep 1 1998 utmpd

There is no undelete command in Unix. Actually there's no delete command either. When you 'rm' file, you are actually deleting it's directory entry via a call to unlink(2). If this causes the link count on that inode to become zero than the inode will be deallocated and all it's data blocks will be put on the free block list. If the link count doesn't reach zero, then the file still exists - Somewhere.

In reality the inode & data will likely live for sometime after the link count falls to zero, in essence until the inode is re-allocated elsewhere. In practical terms however it's gone, forget about it, and start looking for the backup tape.

Opening a file increments the Link count for the period the file is held open. This apparently curious quirk is the way Unix deals with the situation of a file getting deleted whilst something has it open. One side-effect of this is that it is impossible to delete an open file - once the program(s) that has it open exits the inode will deallocated. Before that however the file exists in state of limbo, it exists on disk but has no directories entries pointing to, an Unreferenced File in Unix lingo. More about unreferenced files in the Fsck FAQ.

Inodes are kept in a separate table - the Inode Table. The inode table is a fixed, non-expandable structure that is defined when the filesystem is created by newfs. Corruption of the inode table is the 2^nd worse thing that can happen to a Unix filesystem.

When the inode table is full so is your filesystem, no matter what 'df' is saying about the amount of free space. The size of the inode table is fixed when it is created, there is no command to extend it. Solaris users can examine the state of their inode table using the 'df -e' command.
The following example shows the Linux syntax;

bash% df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda2             179520   75798  103722   43% /

Timestamps

Each inode within a Unix filesystem holds 3 timestamps which are stored internally as 'epoch time', that is the number of seconds since 00:00:00 GMT on January 1^st 1970.

The true file creation time is not stored in most Unix filesystems.

The 'ls' command usually accesses mtime for the '-l' (long listing) or '-t' (sort by time) options. By including one of the two option flags shown above the atime or ctime can be used instead.

The find command can search for files matching timestamp criteria via the -atime,-mtime,-ctime options. See Search for Files and Strings - find for more details.

Symbolic, a.k.a.'Soft' links

To many people they're the best thing since sliced bread, to newcomers they're a source of constant confusion. Symbolic links appear like this;
sun (ksh) % ls -l spool
lrwxrwxrwx 1 root root 12 Mar 11 1999 spool -> ../var/spool

The Symbolic link or 'symlink' to use the jargon is a file that points to another file. In the above example 'spool' points to another file called 'spool' that lives in the directory ../var. The '..' is a clue that this is a relative symbolic link

Why I hear you ask would you ever want a file that points to another file ? The most common reason is to provide a hook to programs for file that has moved.

Symlink in two flavours - absolute and relative. An absolute link always begins with a '/', anything else is relative to the directory the link lives in.

• Symbolic links are created with the command 'ln -s'.
• Symlinks can point to a file on another filesystem
• It is quite possible to create a symlink that points to nothing.
• Symbolic links can point to a directory.

Symbolic links can be broken. As there is no link from the target file back to the symbolic link is it quite possible to delete the target file and leave the link in place. This leads to some interesting symptoms; If an 'ls' shows a file, but when you try to open it you get the error 'xyz: no such file or directory' then most likely it's a broken symbolic link.

Hard Links

The term is an anathema to Unix gurus, there's really no such thing as a hard link. It seems to have come about as twisting of 'Soft Links'. However the term has stuck and is explained here.

The i-node number of a file can be seen using the '-i' option of ls. Consider this 'ls -li' output from a Solaris system;

sun (ksh) # ls -li /etc/init.d/cron 
43 -rwxr--r--  5  root  sys   504    Sep 1 1998 /etc/init.d/cron

sun (ksh) # find / -xdev -inum 43 -ls
   43   1 -rwxr--r--  5 root   sys   504 Sep  1  1998 /etc/init.d/cron
   43   1 -rwxr--r--  5 root   sys   504 Sep  1  1998 /etc/rc0.d/K40cron
   43   1 -rwxr--r--  5 root   sys   504 Sep  1  1998 /etc/rc1.d/K40cron
   43   1 -rwxr--r--  5 root   sys   504 Sep  1  1998 /etc/rc2.d/S75cron
   43   1 -rwxr--r--  5 root   sys   504 Sep  1  1998 /etc/rcS.d/K40cron     

The -xdev option to find tells it not to look at any filesystem other than the one /etc lives on. Inode numbers are unique to a filesystem, but there is likely an inode#43 on other filesystems.

In order to free the 504 bytes of space this inode has allocated to it one must 'rm' (delete) it from every directory shown in the above list. Even then if something has that file open the space will not be freed until the program closes it.

• Hard links are created with the command 'ln'.
• You can only create a 'Hard link' to a file that already exists,
• That file must be on the same filesystem.
• You cannot 'Hard Link' a directory.

Soft or Hard links ?

Where and when to use soft links or hard links... A matter of some debate, and most that hold some opinion, hold that opinion strongly. In my opinion symbolic links are grossly overused, and by contrast hard links underused. Symlinks can be broken, generally cause a lot of confusion, and cause another inode to be allocated for the same file. I believe their use is more widespread because they are easier to see, i.e. laziness. The only places symlinks are needed is when creating a link to a directory, or to a different filesystem.

Mount Points

For files and directories in a Unix filesystem to be accessible that filesystem must be Mounted using the mount(1m) command. The action of mounting a filesystem simply connects that filesystem to the existing directory structure. Under Unix there are no drive letters or volume names as in DOS on VMS, nor are there commands to change which filesystem you are using - simply 'cd'ing to a directory may change that...

Usually all filesystems on hard disks are mounted when the system boots via the file /etc/fstab or /etc/vfstab

The 'df' command is usually used to display the Disk Space usage on a filesystem. Below we use df to show all mounted filesystems on a Solaris machine ('-k' simply means Kilobytes);

sun (ksh) % df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0t3d0s0      47975   17711   25467    42%    /
/dev/dsk/c0t3d0s3     721230  590285   73247    89%    /usr
/dev/dsk/c0t3d0s4      96455   29279   57531    34%    /var
swap                  128408     312  128096     1%    /tmp
/dev/dsk/c0t1d0s5    2100583 1200588  836978    59%    /export/home
/dev/dsk/c0t1d0s6     668423  334350  273915    55%    /opt
/dev/dsk/c0t1d0s7    14584749 13617105  821797    95%    /data

The first column shows the block device file for this filesystem, the last is the mount point.

Before a filesystem is mounted on it a mount point is simply a directory, created with 'mkdir' like any other. After mounting a 'ls' of a the mount point will show the contents of the top of that filesystem. A directory called 'lost+found' always exists at the top of every filesystem and is important - don't delete it. More about that in Fsck, mid-level corruption.

Mount points should be empty directories but there is nothing to enforce this. If you mount a filesystem on a directory containing files then those files will not be accessible until you umount(1m) the filesystem.

sun (ksh) % pwd
/export/home/andrew
sun (ksh) % df .
/export/home (/dev/dsk/c0t1d0s5 ): 1799990 blocks 226083 files 

Devices files

The explanation of Unix device files has been expanded and now lives in it's own FAQ
see - Unix Device files

Superblock

The simple explanation often given about the superblock is that it contains a list of free (unused) blocks in a file system. This is correct in so far as it goes, but the super-block contains other vital information about a filesystem, such as size, and location of key structures such as the inode table. One of the worst things that can happen to a Unix filesystem is for it's superblock to be lost or become corrupt. For this reason most variants keep backup superblocks for use with programs such as fsck. Superblock corruption is discussed further in Fsck, Severe Corruption.