Remove a symlink to a directory

Question

I have a symlink to an important directory. I want top get rid of that symlink, while keeping the directory behind it.

I tried 'rm' and get back "rm: cannot remove 'foo'".

I tried 'rmdir' and got back "rmdir: failed to remove 'foo': Directory not empty"

I then progressed through 'rm -f', 'rm -rf' and 'sudo rm -rf'

Then I went to find my back-ups.

Is there a way to get rid of the symlink with out throwing away the baby with the bathwater?

Answer 1

If rm cannot remove a symlink, perhaps you need to look at the permissions on the directory that contains the symlink. To remove directory entries, you need write permission on the containing directory.

Answer 2

use the "unlink" command and make sure not to have the / at the end

$ unlink mySymLink

Answer 3

# this works
rm foo
# versus
rm foo/

Basically, you need to tell it to delete a file, not delete a directory. I believe the difference between rm and rmdir exists because of differences in the way the C library treats each.

At any rate, the first should work, while the second should complain about foo being a directory.

If it doesn't work as above, then check your permissions. You need write permission to the containing directory to remove files.

Answer 4

Assuming your setup is something like: ln -s /mnt/bar ~/foo, then you should be able to do a rm foo with no problem. If you can't, make sure you are the owner of the foo and have permission to write/execute the file. Removing foo will not touch bar, unless you do it recursively.

Answer 5

rm should remove the symbolic link.

skrall@skrall-desktop:~$ mkdir bar
skrall@skrall-desktop:~$ ln -s bar foo
skrall@skrall-desktop:~$ ls -l foo
lrwxrwxrwx 1 skrall skrall 3 2008-10-16 16:22 foo -> bar
skrall@skrall-desktop:~$ rm foo
skrall@skrall-desktop:~$ ls -l foo
ls: cannot access foo: No such file or directory
skrall@skrall-desktop:~$ ls -l bar
total 0
skrall@skrall-desktop:~$

Answer 6

Assuming it actually is a symlink,

$ rm -d symlink

It should figure it out, but since it can't we enable the latent code that was intended for another case that no longer exists but happens to do the right thing here.