How in the world do you delete a symbolic link named "."?

[Undecided]

FML. I accidentally created a symbolic link named "."

Yeah.

It's not visible in Finder, so we're playing in terminal.

Any idea how to remove this?

EDIT: it was a comma, actually.

 

[fehhkk]

Doing "rm ." doesn't work?

It shouldnt remove the current directory since its not an rmdir command.

 

[Undecided]

Doing "rm ." doesn't work?

It shouldnt remove the current directory since its not an rmdir command.

No, because it thinks you're trying to use . to delete the directory.

But I figured it out.

Delete by inode number instead of file name. OMG.

find . -inum inodenumber -exec rm -i {} \;

Whew.

 

[chown33]

I'm glad you figured out how to delete it, but I'd like to know how you created a symlink named "." in the first place.

I'm not doubting you, because I can think of at least one obscure way. But nothing I can think of is something that happens by accident.

 

[Undecided]

I'm glad you figured out how to delete it, but I'd like to know how you created a symlink named "." in the first place.

I'm not doubting you, because I can think of at least one obscure way. But nothing I can think of is something that happens by accident.

ln -s /source/file/to/link/to .

 

[chown33]

ln -s /source/file/to/link/to .

On which OS version? And what file-system format is the destination disk?

Whatever OS version or file-system I try that on, it sees "." as an existing directory. That makes it fall into the pattern "ln -s source_file target_dir", which creates the file "./leafname", where "leafname" is the final pathname component of source_file. See the 'ln' man page for details.


If there is some directory that doesn't have an entry named ".", then that directory is damaged. Also, the "." entry should always refer to the enclosing directory itself. The fact that this happened at all suggests you may have some latent file-system damage. Consider running "Verify Disk" in Disk Utility.app, and see if any errors are listed.

 

[Undecided]

On which OS version? And what file-system format is the destination disk?

Whatever OS version or file-system I try that on, it sees "." as an existing directory. That makes it fall into the pattern "ln -s source_file target_dir", which creates the file "./leafname", where "leafname" is the final pathname component of source_file. See the 'ln' man page for details.


If there is some directory that doesn't have an entry named ".", then that directory is damaged. Also, the "." entry should always refer to the enclosing directory itself. The fact that this happened at all suggests you may have some latent file-system damage. Consider running "Verify Disk" in Disk Utility.app, and see if any errors are listed.

Mmmm, going through the terminal history, I guess it was actually a comma! Hard to see from 12 feet away.

It went like this:

ls

Documents

ln -s Documents/ ,

ls -la

total 40
lrwxr-xr-x 1 me staff 10 Sep 26 18:15 , -> Documents/
drwxr-xr-x+ 5 me staff 170 Sep 26 18:15 .
drwxr-xr-x@ 60 me staff 2040 Sep 26 18:16 ..
-rw-r--r--@ 1 me staff 15364 Sep 23 20:43 .DS_Store
drwxr-xr-x+ 18 me staff 612 Sep 10 15:59 Documents

Maybe "rm ," would have worked after all...still, I learned about inodes.

 

[chown33]

Mmmm, going through the terminal history, I guess it was actually a comma! Hard to see from 12 feet away.

It went like this:

ls


ln -s Documents/ ,

ls -la


Maybe "rm ," would have worked after all...still, I learned about inodes.

That makes more sense. Thanks for taking the time to clarify it.

Yes, "rm ," would have worked. You can test it with these commands:

touch ,
rm ,

The first command makes an empty file. The second removes it.
You can do this in any directory where you have write privileges.