Recently we made a number of changes to better handle symlinks, and overall the implementation should be better.
To address your comments about settings you’ve tried:
ignore_inodes
is Windows-only and likely isn’t going to do anything useful for you. It reverts to trying to de-dupe folders based on the list of files and subfolders. This would only be useful if the filesystem you are using on Windows is providing junk data for the device id and inode. I do know that sshfs (based on a recent user report) is broken in this way. That user found Expandrive to actually implement these filesystem features correctly. So if you are on Windows and using sshfs, it might be worth checking out Expandrive.
follow_symlinks
will turn off cataloging the files and folders inside of a symlink, even if it hasn’t been seen before. Typically this is not the behavior you are going to want, unless you project has a symlink out to some parent folder that is going to cause a large part of your hard drive to be cataloged.
In regards to changes recently to symlinks, we no longer show the expand arrow in the sidebar when a duplicate folder is detected. These folders are shown with a chain link in the icon. Typically duplicate folders are caused by a symlink to another folder in the project. The reason we don’t show the contents is that we can’t definitely know if the duplicate folder will result in catalog recursion. For example, using symlinks it is possible to create a symlink to an ancestor folder. If we try to include these in the catalog (which powers Goto Anything), the catalog will never finish being generated and will never stop growing in terms of memory usage.
So, we don’t show the arrow for duplicate folders, but we do show the link icon. We also recently added a context menu entry on link folders named “Reveal Link Source”. This will jump to the first (or if it exists, non-symlink copy) of the folder so you can expand it to view the contents. Another change we made was that previously we considered the first copy of a duplicate folder to be the “source”, but now if we come across a duplicate folder that is not a symlink, we use that as the “source”.
Another change related to symlinks is that previously on Window and Linux we did not handle filesystem notifications for folders that were symlinks. This resulted in “source” folders that were actually symlinks to not update as files and subfolders were created or deleted. With our improved filesystem notifications, we can now detect those changes, and properly update the listing in the side bar.
All that said, it is still possible that you are experiencing issues with symlinks. If you can provide some details about the situation, along with the output from your Sublime Text console, that will help try to pin down what is happening. The best place to do this will be https://github.com/SublimeTextIssues/Core/issues/new since we can tag it, mark it with milestones as progress is made, etc.