I had no problem in the past with creation of symlinks inside the ~/Library/Application Support folder, but not anymore. the "ln -s" command in Terminal creates only the alias now, instead of symlink. I really need help with this problem.
MacBook Pro, OS X Mountain Lion (10.8.3)
Yes, I know what "ln -s" command creates and I have used it in the past without problems - but this time it simply doesn't want to create symlink inside ~/Library/Application Support folder, it insists on creating an alias.
And yes, there are gazzilions of reasons for creating a symlink in that folder - many applications insist on placing their data folders there. I keep only system and applications on my boot drive (128 GB SSD) and all data on the second HDD - it simplifies backup and recovery, simplifies booting from cloned system volume with full access to the folders outside SSD is there is a problem and I need to reinstall OSX, plus there are no 2TB or larger SSD's yet on the market (not that I could afford one at current prices per GB of SSD). So, I keep iTunes (over 500 GB), photos, movies (another 500+ GB) outside of SSD on the HDD inside the MyMedia volume and all my documents (over 100 GB) inside MyDocs volume on HDD.
One of those offending programs insisting to keep everything inside ~/Library/Application Support folder is Adobe Air used by Zinio Reader. I have a large, ever growing Zinio library (over 15 GB as of now) and shortly after getting SSD and upgrading to Mountain Lion ages ago I was able to move the Zinio library to HDD and then create a symlink to it in ~/Library/Application Support folder's location using "ln -s" command. No problem at all. I hope the above long explanation tells you clearly that there are reasons for creating aliases and symlinks in ~/Library.
Now my HDD is getting old and doesn't have enough space anymore, so I replaces it with new larger HDD. Everything works, except the problem with creating a symlink to Zinio library inside the proper location inside ~/Library/Application Support folder. Like I said - I tried all, I started the easy way with SymbolicLinker service - it created an alias instead of symlink. Then I tried SymLinker app - it doesn't allow me to select any target inside ~/Library/Application Support folder. Finally I turned to trusted Terminal and used "ln -s" command - it created an alias again, instead of symlink.
Not in my current case - every time it is just an alias, not a symlink. I checked, re-checked and checked again - an alias every time. This is the very reason I'm seeking help here.
And Adobe Air doean't like aliases, thus my Zinio Reader doesn't want to work as it can't find the Zinio Library.
The Library folder is hidden so those with not enough knowledge cannot mess with it. Any advanced user can make Library folder visible anyway. Moving entire Home folder creates more problems that it solves.
My problem is that in the past I was able to create a working symlink inside ~/Library/Application Support folder using "ln -s" command without any problems and now the very same command creates only an alias.
This is the problem I'm looking for help with, what to do to force "ln -s" command to create a symlink where I want to have it as it supposed to do, not how to organize my files - no disrespect intended.
The command line is ln -s source target. Target can be just a directory name. If the directory does not exist it will be created in the given path.
Alternatively, you can install one of these services:
I use the first one, personally.
Thanks for reply, but as I described the "ln -s" command creates only an alias, doesn't want to create a symlink. Same thing with both applications you mentioned - in my particular case they don't work either. SymbolicLinker service creates an alias and when trying SymLinker the app doesn't allow me to select any target folder inside ~/Library/Application Support.
The "ln -s" command only creates symbolic links, not aliases. Also, there is no reason to be creating either symbolic links or aliases in that location.
Really, they do create a symlink. Just looks the same as an alias.
andrewm8 wrote:
I hope the above long explanation tells you clearly that there are reasons for creating aliases and symlinks in ~/Library.
Sorry, but no. The Library folder is hidden for a reason - to keep you from doing that very thing. You have ignored that and gone ahead and done it anyway. Now you are reporting something completely out of left field. Correlation or causation?
If you have more data than will fit on your SSD, then move your entire home directory to your hard disk. That is completely supported and every bit as fast as your current, hand-crafted setup. No problems with backups. No terminal needed.
If you are interested in how to move your home directory, I would be glad to help. The hardest part will be undoing all of your symbolic links.
andrewm8 wrote:
Moving entire Home folder creates more problems that it solves.
Moving the entire home folder is perfectly save, actively supported by Apple, and will not even be noticed.
My problem is that in the past I was able to create a working symlink inside ~/Library/Application Support folder using "ln -s" command without any problems and now the very same command creates only an alias.
This is the problem I'm looking for help with, what to do to force "ln -s" command to create a symlink where I want to have it as it supposed to do, not how to organize my files - no disrespect intended.
Alas, I cannot help with that because I have never seen OS X do that since the first days of the public beta. I can tell you how to move your home directory and get the greatest use and performance from your SSD drive. But I can't make the sky turn from green to purple.
The man page doesn't indicate any changes in the ln command. Since it is unix, it should be creating a symlink. The Finder may present it as an alias, but that doesn't necessarily mean it is not a symlink.
The GUI may not support the symlinks in that folder, which may be the problem.
What about it is indicating it is not a symlink?
I used the symlink before and in the same location (~/Library/Application Support folder) to my Zinio Library on the old HDD. Now I changed the HDD (thus location of Zinio Library changed) and cannot create symlink to it, all I'm getting are aliases.
What indicates that they are aliases and not symlinks? The one indication is the size - aliases created are about 5 MB in size, while my old symlink was mere 75 bytes.
I reinstalled the old HDD and the restored old symlink from the clone and it properly tells Zinio Reader where it's Library is. So, nothing wrong with using the symlink in that location. Just cannot create new one.
Have you tried creating it somewhere else and moving it into the app support folder?
Yes, I can create symlink in other than /Users/ location, but it is not recognized by Zinio Reader (or by Adobe Air framework) after I move it to proper place in the app support folder. It is really strange and in my entire experience with OSX (since it's inception) I never encountered this kind of problem.
Finally it works. What I did:
1. repaired permissions
2. run 10.8.3 Combo Update
3. after restart repaired permissions again
It fixed the problem of not being able to create symlinks in app support folder. Something must have been corrupted in my system and the above cured it. Thanks to everyone for help.
That seems completely odd. I can't imagine the unix command creating an alias, unless it was handing off the task to the GUI somehow. The other program you mentioned did the same thing.
I guess you didn't happen to try after repairing permissions and before the Combo Update?
Since permission repair does not affect the home folder, I would imagine it was the combo update.
Could those symlink programs have done something to the system?
How to create symlink in Application Support folder?
