Thomas Jachmann 4 years ago • updated by Eduardo Vaz de Mello 3 months ago 46
Since upgrading to Build 2157, the Sidebar displays symlinked folders in a strange way:

The source folder appears to be empty, the first symlinked (target) folder contains all the files and all other symlinked (target) folders pointing to the same source folder appear to be empty as well.

It is nice, that files in symlinked folders aren't visible in file search an in "Goto File" to avoid duplicates. But why only display them in the first of the symlinked folders?

I'd like to see the symlinked folders/files in the sidebar (even better: display a marker on the folder/file symlinks), but only see the original files in "Goto File" and also only search the original files when finding in files to avoid duplicate occurences of the same code in the search results.

BTW: Directly symlinked files currently appear in all locations, you also find both occurences in "Goto File".
This seems to be partially fixed in build 2158. All the files are displayed in the sidebar again, in all folders - original and symlinked folders.

Still, I'd like to see something like only seeing the original files in "Goto File" and "Find in Files" to avoid duplicate search results and also, some marker on symlinks in the sidebar would be nice.
Today (build 2164) the files show up in the last of the symlinked folders. This seems to behave a bit capriciously.
Build 2181 doesn't have this behaviour and symlinked folders are not showing files in the sidebar. The folder open/close arrow shows fine, but no files.
In OS X Lion (at least) it's the opposite. The files are shown in the symlink but not in the actual directory...
I think this depends on the ordering of the folders, meaning on which folder (original or symlinked) is displayed first in the tree.
+1. This is kinda a showstopper for me. I agree with Thomas that the symlinked directories should at least be indicated in the project sidebar (possibly just that and not showing any files in it). Also the Goto Anything shouldn't show you the files in symlinked directories.

Looking forward on seeing the fix. Can I somehow subscribe to this in order to find out when it actually is fixed? 

This is very confusing and a bit of a showstopper, sice I use lots of symlinked folders and files in my project.
Agreed on this. All files should be shown in all subfolders (and the difference between a symlink folder and a normal one should probably be shown via color or different icon). 
It's still exists and it's VERY frustating: I can't see symlinked directories in sidebar (through samba sharing.)
Sublime becomes almost useless if you have a symlink-heavy system... :(

I am getting very sporadic behavior with this.  Sometimes it works, sometimes it doesn't.  My current theory is if you create a symlink while Sublime Text 2 is open, it will not work.  Restarting the program after the symlinks are in place seems to resolve the issue.


Build 2217 is still having problems with symlinked folders. The folders themselves appear in the list but the files inside the folders are inaccessible. Bummer


ack I just ran into this. really concerning as a lot of my team members use sublime. help would be greatly appreciated!

same problem here.. please fix this

I've been having this problem ever since I installed Sublime, it's pretty annoying, will this be fixed in Sublime 3?

I have the same problem, hope it will be fixed once cause it's very annoying.

Same problem in OS X Mountain Lion & Mavericks


Still same problem. Sublime 3 build 3047, Mac OS X 10.7.5.

Thanks for disregard for Sublime developers...


I can confirm this issue still exists on ST build 3047 (on OSX 10.8.4).


Symlinked content still appears in directory tree even when I've deleted it.

Sublime build 3047

Mac OS 10.8.4

No symlinks show up in project folders for me either.  Version 2.0.2 Build 2221

OSX 10.9


Same issue here. I was just explaining a Symfony projects directory structure to a new team member and lo and behold my entire public folder (which is symlinked) appeared empty. Confused the hell out of both of us. Then I pop open the terminal or finder and of course those files are where they should be. This is a pretty serious bug.

Any action on this in either Sublime2 or 3? 


Symlinked content not displaying correctly for me either,

Mac OS 10.8.5

Sublime Build 3047

Would love to have a fix for this!  Thanks for all the great work on this app to date!

This problem seems fixed in sublime text 3
I do not agree, I've updated to ST3 build 3059 and still have this problem. Running Ubuntu 13.10 64bit.
Fair enough.  i'm on Mac OS X 10.8.5
OSX 10.9.1, I can confirm this problem still occurs with ST3 build 3059. Symlink shows the content of the directory, while symlink target appears empty in sidebar.
I have the same problem with Windows 7 / ST3 3059
Sidebar files or files in the folder doesn't show :(
I'm on OSX 10.9.4 using the most recent Sublime Text 3 dev build (3064) and this bug still exists. However, since the recent introduction of icons in the sidebar it does appear that Sublime can distinguish between normal directories and symlinked directories, but cannot list their contents. See the attached screenshot, the /public directory is a symlink. I have it expanded, but its contents are not listed. If I go directly to the symlink target and expand it the contents are listed. Really would love a fix for this one, its a pain during development to have to be constantly hunting down symlinked files.

This is indeed still an issue. Symlinked folder is shown incorrectly as a real folder and shows all contents of symlinked dir. Source/target folder is incorrectly listed as a symlink and shows no contents.
This has been a source of frustration for me for a while now. I am currently using build 3065. My build system creates various symlinks in the target back to source directories. Opening the target directories works just fine, but the source directories are inexplicably empty.

I have found that the Side Bar: Refresh or Project: Refresh Folders commands will cause the sidebar to reveal an additional level of files and folders each time the command is used, but this is less than ideal, particularly with deeply nested folders ... 
Exactly the same issue like Richard Woordward.
Updated today with build 3065, symlinked folders are just empty. It's quite annoying really to have seen so many people having this problem & not being resolved so far....
Hopefully there will be a fix for that...
Here's a fix that worked for me - Mac OsX 10.9.2-http://stackoverflow.com/questions/16199581/openin...

Answer from bjtran1234 - is what made it work:)
Hope it'll help ...
 The stackoverflow link you provided addresses opening Sublime Text from the command line.  How does this address appearance of symlinks to folders in the Sublime Text side bar?  I don't get how the suggested answer addresses the bug this discussion is concerned with.
Problem still exists... build 3065
the hash folders = sym links, the numbers (1-6) = real folders.

... and it's annoying as shit. I can't open those folders.
@Tobias-have you tried opening only this folder in sublime.
& if you tried the above fix, I guess you have closed & opened sublime again?
Problem indeed still exists, and is perfectly described by Richard Woodward.

Caprica6, the issue you are referencing is something completely different, so I don't see how it fixed this situation? I've tried the answer from bjtran1234 that you pointed at, but it's not working... 

So, here's another one hoping for a fix :)
+ 1 for fixing this issue as described by Richard Woodward.
Just fyi - still the same issue - the fix in on stack won't help - I didn't open it via console. I have it all setup as a project. I tried all kinds of solutions even downgraded python - NOTHING works. a folder that has a symlink to it won't display it's contents unless manually selected and refreshed, but even then its subfolders act the same way. it is very, very annoying for us here because our whole system uses links to about 200 folders in which we work daily...

just to describe it in more detail: the symlinks themselves show the content just fine, they are displayed as "folder" icon, the folder that is the destination of the symlink is shown as symlink and won't be automatically scanned. it is very confusing why this would happen.

solutions tried:
project -> refresh folders = no change
downgrade python to 2.7 (from 2.7.9) = no change
using user setting ignore_inode = no change
refresh folders at upmost parent manually = refreshes only first level, not folder content of target symlink (half working...)
SyncSidebar extension = turns out its only for ST2
uninstalled sidebar enhancement extension = no change
created test folder outside dropbox and or turned off dropbox = no change
I think I did like 2-3 more = no change

I don't know why nobody is addressing this further up to be fixed.

EDIT - IMPORTANT - Here is a partial fix:

go into "edit project" and change true to false:
"follow_symlinks": false,

this now does NOT display any symlinks anymore BUT it displays all target folders correctly and loads their contents.
well... I guess I'll go with this for now because it saves a lot of time.

I have succeeded in creating a symlink directory that shows up in the sidebar, and is navigable:

  1. Create a symlink directory (using ln -s in the console: instructions)*, to an existing directory (or child directory) in the sidebar.
  2. At first, a symlink icon will be shown, instead of a folder icon, for the new symlink directory. But it will not be navigable.
  3. Close submlime test an reopen.
  4. You may then see the symlink directory have the icon of a directory, and be navigable like a directory.
* Using a Mac OS X "alias" will not work using these instructions.


OS X 10.10.2
Sublime Text 3083
Just opened a project with symlink directories using build 3083 and found the directories to be navigable to my surprise! Great, time to give sublime another go!

-edit- Unfortunately, the original directory is not navigable, only the symlink directory :(
I've also noticed some trouble with this solution of using a symlink: when opening a file from a directory search in a symlinked directory, it will open the original, and treat it as a different file than the symlinked file, leading to overwrite issues if there are different unsaved changes in what Sublime believes are two files.
How can a filesystem feature like symlinks cause such long lasting trouble?
This ticket was opened over three years ago. What's the problem with it?
Agreed. Acknowledgement of the bug and a fix would be much appreciated. For anyone using symlinks heavily during development this is a real pain.
Despite not being able to navigate through symlinked directories: Could you please make the particular icon somehow configurable? The black arrow looks terrible on dark sidebars. For instance, consider the screenshot posted by Tobias O.: http://i.imgur.com/x2YH6Dp.png
4 years later the problem remains... Since i heavily rely on symlinks to manage assets in my projects, this issue became a showstopper.
Rather strange indeed, I'm still using ST2 but I thought - even if only for ST3+ - this would be done by now. I don't care that much on having a terminal in the background only to check if this or that file/dir is a symlink, but if we only had any feedback on why this can't be done by vanilla ST itself it'd be less frustrating.

By the way, anyone knows any package that'd only indicate in the file tree side tab if a file is a symlink? I've tried some but none would do that (ST2 if possible).