0

It is not possible to rename symlinks to one default folders in your home folder (~/Documents, ~/Desktop etc...) using Finder
This works in Terminal.

Update 2

To test:

  • run ln -s Documents "Documents symlink" in terminal.
  • verify you can't rename ~/Documents symlink in Finder
  • verify that running mv "Documents symlink" "Document symlink new" works
|improve this question
  • Path Finder by cocoatech.com is a finder replacement that is far more powerful and you can try it for free. – bmike♦ Aug 19 '11 at 18:24
  • @bmike, you can do this. It's my script that is breaking it. – Tyilo Aug 19 '11 at 18:32
  • I found out was not caused by my script and it is also failing when just using ln -s – Tyilo Aug 19 '11 at 18:41
  • 2
    The last edit should have edited to the question not removed the question as now it makes no sense – user151019 Aug 19 '11 at 20:32
1

I've started using an application called DTerm in the last few weeks, and it could help to make this task relatively painless.

The point of DTerm is to provide a command line specific to where you are, and with context to the application you're in. While you're in the Finder, DTerm provides a command line in the current folder in the front-most/active window you're viewing.

I have an Applications folder in my Home Folder, and a symlink called bin pointing to it for compatibility's-sake.

Finder View of a bin symlink to Applications

Note how the folder icon carries the standard Applications icon, but has the shortcut arrow.

By invoking DTerm using a configured keyboard shortcut, I can immediately rename that folder.

mv bin bon, no errors

There's three things going on here:

  1. The input field which I've typed the command into.
  2. The command line is expanded/returned for things like variables and globbing (using the * for matching files).
  3. The empty field under the returned command is a static text field for output/errors. Neither of which occur when using the mv command, at least not in my invocation.

And then of course, I rename it back:

mv bon bin, no errors

Best of all? DTerm is available completely free of charge. The link at the top of this post will take you to the author's website, and here is a DTerm Mac App Store Link.

|improve this answer
0

FWIW, I'm on Lion as well, and I just tested it:

cd ~/Desktop
touch foo
ln -s foo bar

Then I went into the Finder and renamed bar as baz. Back in Terminal:

ls -l ~/Desktop

outputs:

lrwxr-xr-x   1 kiezpro  kiezpro      3 Aug 19 18:42 baz@ -> foo
-rw-r--r--   1 kiezpro  kiezpro      0 Aug 19 18:42 foo

What's your exact problem then? Can you edit the symlink's file name at all? Do you get any error message? Or can you edit the file name and it just jumps back to the original one? Additional info: I'm using 10.7.1, and I'm using a case sensitive file system as a mortal user without administrative privileges.

|improve this answer
  • Ok it is only a problem with folder symlinks – Tyilo Aug 19 '11 at 16:53
  • Works here with folder symlinks as well. Selected the symlinked folder name, pressed Enter, changed the name, pressed Enter again -> done. What exactly does not work for you? – nohillside♦ Aug 19 '11 at 16:56
  • It works when creating a new one, but this has been created by an automator script. – Tyilo Aug 19 '11 at 17:16
  • The funny thing is, I went on with my answer assuming there was a problem with doing it the standard rename method, but like patrix I have to say that using Finder rename on file/folder symlinks works just fine for me too. Regardless, my answer remains intact, as it is a workaround for this issue no matter the cause. – Jason Salaz Aug 19 '11 at 17:20
  • See updated question please – Tyilo Aug 19 '11 at 17:27
0

This might have more to do with the extended attributes of some special folders - rather than something inherent in the handling of sym links in Finder.

Have you made sure there are no extended flags on any of the directories before running your script?

ls -lo ~ do pay attention to the -O, -P and -L flags when looking at links.

Here is a command that removes a few flags that can cause you grief:

chflags nohidden,nosappdn,noarch,nouchg,noschg <file>

It's best to be precise and not simply unset everything - these flags are deployed when needed to make the system work as intended. The manual pages for both ls and chflags go into detail if the abbreviations or syntax is unfamiliar.

|improve this answer
  • drwxrwxrwx@ 35 Tyilo staff - 1190 Aug 19 17:50 Documents lrwxrwxrwx 1 Tyilo staff - 22 Aug 19 21:11 Documents symlink -> /Users/Tyilo/Documents And yes I screwed with the permissions to test if it caused it. Btw it needs to be a capital O – Tyilo Aug 19 '11 at 19:11
0

This seems to have been fixed in Mountain Lion.

|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .