• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3460
  • Last Modified:

difference between unlink and rm

     I have a normal file which is NOT a soft/hard link. When I say unlink <file name> the file gets removed. Can somebody explain this behaviour? Since the file gets removed is it equalent to rm <file name>.
     I'm writing a bourne shell script where I have check for only the softlinks and remove it. How do I do it?
Thanx in advance,
- Jacob
2 Solutions
    link  and  unlink  directly invoke the link(2) and unlink(2)
     system  calls,  performing  exactly what they are told to do
     and abandoning all error checking.  This  differs  from  the
     ln(1) command. See ln(1).

     While linked files and  directories  can  be  removed  using
     unlink  , it is safer to use rm(1) and rmdir(1) instead. See
     rm(1) and  rmdir(1).

man unlink
to learn more details.

    To find all the symbolic link under the current dir, you can do:
    find . -type l -print
    PS: it is type L,a  lower case L

    To check if the file is a symbolic link, you do:

    if [ -L filename ] ; then
      echo "filename is a symbolic link"

if you unlink a file both the pointer and destination still exist except you can't see them

for example if /opt/softwareinstall is linked to /extradiskspace/app1

when you cd to  /opt/softwareinstall you will see everything in  /extradiskspace/app1  

if you remove this link then you will have to go to  /extradiskspace/app1  to see the same files and /opt/softwareinstall will be empty

Be very careful when using unlink if there are dependencies and you unlink you could run into major problems
Think of unlink as the "raw" version of rm - rm gives you more control over things like properly removing directories, recurive directory removal, error-checking, etc.
As already mentioned, rm and unlink do basically the same thing but rm gives you more control.

At the file system level, both unlink and rm do basically the same thing.  Look at the below:

soneill@linux:~> ls -la
total 204691
drwxr-xr-x  123 soneill  users        9000 2004-08-20 17:38 .
drwxr-xr-x    5 root     root          120 2004-07-02 15:25 ..
-rw-r--r--    1 soneill  users      298773 2004-05-27 17:37 9960_What _works_with_what.pdf
drwxr-xr-x    2 soneill  users          72 2004-01-17 14:57 .acrobat
drwx------    2 soneill  users         184 2004-06-26 11:00 .adobe

Specifically look at the second column.  Notice for the 9960_What.....pdf file the value is 1.  That is the link count.  The link count shows you how many times a specific inode has been referenced by an directory entry.   If you create a hard link to a file like this:

soneill@linux:~> ln 9960_What\ _works_with_what.pdf sean.pdf
soneill@linux:~> ls -li 9960_What\ _works_with_what.pdf sean.pdf
 193343 -rw-r--r--    2 soneill  users      298773 2004-05-27 17:37 9960_What _works_with_what.pdf
 193343 -rw-r--r--    2 soneill  users      298773 2004-05-27 17:37 sean.pdf

Notice I added the -i switch to the ls command which prints the inode number as the first column.  The link count column is now in the third position.  Notice the inode numbers are the same and link count is now 2.  If I remove sean.pdf:

soneill@linux:~> rm sean.pdf    # "unlink sean.pdf" would do the exact same thing
soneill@linux:~> ls -li 9960_What\ _works_with_what.pdf sean.pdf
/bin/ls: sean.pdf: No such file or directory
 193343 -rw-r--r--    1 soneill  users      298773 2004-05-27 17:37 9960_What _works_with_what.pdf

Notice the link count for the 9960.....pdf file went back to 1.  If I were to do a remove on 9960....pdf, the inode link count would goto 0 which "removes" file.  Only when the link count drops to 0 is a file deleted.

Actually to get really specific about it, the filenames you see in a ls listing are nothing more then references that POINT to a specific inode.  The inode structure actually holds a small amount of the file's content.  The rest of the file is traversed using a rather crazy reference scheme - but it works.  So think of the inode as "the file".  But an inode is simply a number in an "ls" listing.  The pretty-eye-catching name you see in a directory listing is nothing more then a way for us stupid humans to know what a specific inode is for because we assign meaning to that name.

Then there are ways to play with inodes:

- Hard links - this simply pointing a new directory reference to an already existing inode.  Basically what I did above in my example.  Hard links must point to inodes that exist in the same file system

- Soft Links - This is a directory entry that point to another directory entry (be it in same file system or another file system).  So basically:

directory entry -> directory entry -> ..... (directory entry) -> inode

Remember, a directory entry is nothing more then a name and it contains no data of any file.  So its pretty easy to make a stale or broken symbolic link cuz the system doesn't check to see if the directory entry you are pointing at really exists.  For hard links, it always checks so you can't create a broken hard link.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now