Sublime Forum

Still problem with symbolic link-folders

#3

Well I have just tried this out in Linux Mint with ST3, and everything behaves as expected. The linked folders correctly appear as real folders in the sidebar and expand to show their files. The indexer also seems to behave correctly across these symlink’d folders as well.

So probably the reason you’re getting no replies is because no-one sees the problem.

  1. If you’re using “old” project files, try a blank sublime window then just dragging the folder in again. Option “follow_symlinks” is specific to folder entries within project files afaik, and the setting won’t be added automatically to old project files, but will with newly created and saved projects.

  2. Failing that, try a virgin, portable copy of ST3. There might be some interference from a plugin or something.

(using build 3061 of ST3)

:smile:

0 Likes

#4

[quote]Well I have just tried this out in Linux Mint with ST3, and everything behaves as expected. The linked folders correctly appear as real folders in the sidebar and expand to show their files. The indexer also seems to behave correctly across these symlink’d folders as well.

So probably the reason you’re getting no replies is because no-one sees the problem.[/quote]

As I wrote I’m using Mac OS X and not Linux. So mabye that’s the reason for the difference.

Meanwhile I upgraded to Mac OS X Mavericks – the problem still exists.

And I’m really disappointed by the sublime text-team that there isn’t any support for this paid software!

0 Likes

#5

I have the same problem :frowning: Hope it will be fixed soon as there is no that good editor I can move on quickly.

0 Likes

#6

I found temp solution. When you see folder that doesn’t open click “Project” -> “Refresh folders” and try again.
Now you can see content of all displayed symlinked folders.

But in this case when you “Find In Files…” you’ll see duplicated results from both real and alias folders.

1 Like

#7

I see it’s very old issue that still hasn’t been resolved.
Any hopes for this to be looked at?

In bigger projects i.e. Magento where symlinks are used for template files this is really exhausting having to press refresh folder list each directory under a folder which’s also a symlink.

0 Likes

#8

+1

I’m seeing this problem with ST3 build 3103 as well.

0 Likes

#9

Having the same issue here (Debian / 3103).

I would rather see the actual symlink with a special icon in the browser than the second occurence of the same referenced directory (which, in addition, has a buggy behavior).

0 Likes

#10

Have the same issue here macOS Sierra.

It would nice also to have the CMD + P fuzzy search handle the file path including the symbolic linked one.
Any time plan for fixing this issue?

0 Likes

#11

+1

Feels a bit strange that this hasn’t been acknowledged (let alone fixed) yet. After all, it’s been around for a while now …

0 Likes

#12
0 Likes

#13

Part of the issue with symlinks is that they can be recursive. Due to the way the list of open folders/files work, that could result in an infinitely expanding list of files and folders, hence when a symlink is detected, it is not processed, but logged as a duplicate.

From reading various reports, it does seem there are a couple of edge cases here where Sublime Text may incorrectly detect the symlink as the original. This can lead to issues with folders and files being refreshed since many filesystem monitoring APIs will not follow symlinks.

I’ve been working on the sidebar implementation recently. This should open up the possibility of improving the handling of the edge cases with symlinks. That said, I’m not working on symlinks right now, and I can’t promise a timeline for exactly when I will work on them.

4 Likes

#14

Great to hear that after nearly 3 years there is a reaction. Currently I don’t use Sublime Text because I’m really disappointed about the poor support. I hope there will be a fix so I can return to Sublime Text.

0 Likes

#15

I was having the same problem, a bunch of folders were not showing their contents and being marked as symlinks even though they were regular folders.

The only thing that solved my problem was adding “ignore_inodes”: true to my preferences file.

Hope it helps

0 Likes

#16

I have a problam like this too.

When copying folders to somewhere sublime views them in the Folder view, they appear as symbolic links, but they are not.

That is, maybe linux copy works that way, first creating symbolic links, I have no idea. But Sublime shows the folders as symbolic links, when they are indeed just regular folders.

Thus, I cannot open them. And that is a bug in Sublime.

0 Likes

#17

This problem seems to get worse with every update to ST. ignore_inodes and follow_symlinks don’t seem to have any effect and every time I open a project I end up with a bunch of random folders that Sublime ignores.

0 Likes

#18

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.

1 Like

#19

Hi Will,

Thanks for your quick reply. I am actually using Build 3176 on Windows, accessing project files hosted on a samba share. I don’t see a “Reveal Link Source” menu entry on the linked folders.

I never had any problems with ST 2, did that handle symlinks differently?

In my console I’m getting a load of notifications along the lines of
scan: /Z/symfony-ict-ccp/apps/frontend/modules/report has been seen before, skipping (using content fingerprint) previous path: /Z/symfony-ict-ccp/apps/frontend/modules/reportConfig fingerprint: 1851290627273671656

0 Likes

#20

Hmm, this would seem to be a bug then. Ideally if a folder is marked a duplicate, it should be able to jump to the source.

Honestly, I’ve never worked on the ST2 codebase and Jon was well into the ST3 beta before I started with the company. But, I know since I joined in 2016 we’ve made significant changes to most aspects of the editor. My hunch is that it was all much simpler in ST2, and I know there were quite a number of bugs with symlinks.

I’m curious, do you get the content fingerprint duplicate messages on ST2?

This indicates that your machine doesn’t seem to be getting inode (or file id in Windows terminology) information for the samba share files. What version of Windows are you using? I feel like we had checked this recently, but that it was reporting inode info, however it may depend on the version of Samba and the version of Windows.

0 Likes

#21

Yes I think so. Although in my case I don’t think it would help as the folder is not actually a duplicate.

No, nothing in the console that looks even remotely similar. It just opened up the same directory structure without issue.

Is there any option to disable the symlink check altogether?

0 Likes

#22

No, per my previous comment:

0 Likes