Sublime Forum

File tree reload

#4

Thanks for the reply, unfortunately neither of those work. Upon requesting a refresh it takes a couple minutes at best for the changes to appear and the spinning loader to stop. Yes the file structure is pretty large (basically a project and a virtualenv for the project) but that shouldn’t mean a huge delay like that. Seems like a logic flaw to refresh ALL folders when the user is asking to refresh just one.

The fastest way I’ve found to get a refresh is actually to quit sublime and reopen it (which is fairly disruptive). It’s almost instantly that it updates on restart, again pointing me to the idea that this is actually a problem with sublime, not the OS/FS or me.

0 Likes
#5

Sublime Text doesn’t cache the folder list, per se, but rather relies on filesystem event notifications to show changes. A filesystem like SSHFS doesn’t support that, hence the behavior you see.

1 Like
#6

I have the same problem, but am not using SSHFS. I’m running OS X (10.11.3), and am viewing my local file system (i.e., /Users/{username}/path/to/src), in Sublime Text (build 3114). Any changes I make–whether initiated from within Sublime or from finder/terminal–take minutes to be reflected in the Sublime sidebar.

Refresh doesn’t help, and as with volksman’s earlier comment, the fastest way to get Sublime sidebar to update is just to quit and reopen the app.

0 Likes
#8

@wbond great respect and thanks for all you have done for sublime… :slight_smile:

While the mechanics of SSHFS are as they are a refresh of the folder should see the changes, yet it most often does not. In addition to that other text editors don’t seem to suffer from the same issue (they just have plenty of other issues).

I’m totally fine with a “refresh” if that’s the only way, it sure beats a quit/reload, but even that seems to not work most of the time.

0 Likes
#9

Just an added note, at the very least if Sublime creates the folder or file it should at the very least refresh just the parent in the tree no? But even this sometimes takes forever to update.

0 Likes
#10

Any ideas on how to speed this up? Why does closing and reopening work so much faster than refresh/reload? Could I maybe write a plugin that would do similar?

0 Likes
#11

I’m not really sure why that would be the case – I haven’t yet done any work on the FS notification layer. If you open an issue at https://github.com/SublimeTextIssues/Core/issues and try to provide a way to reproduce it will get on our list of things to try and resolve.

0 Likes
#12

Thanks for the suggestion. I’ve created https://github.com/SublimeTextIssues/Core/issues/1409

0 Likes
#13

I hope this Issue don’t remains in the forgotten, because is very tedious to be closing/opening to refresh folders

0 Likes
#14

Was excited to see all the sidebar improvements in todays release but sadly this didn’t get addressed at all. Seems like such an easy win. :frowning:

0 Likes
#15

Any way to put a bounty on this? A year and zero movement on what’s clearly a stupid caching issue.

0 Likes
#16

Bumpity bump. minor revision and still no movement on this. Pretty please?

0 Likes
#17

It would seem that the FS you are using isn’t sending notifications when new files are created, etc.

If you are using sshfs, perhaps see if something like Expandrive is a better implementation (for now)?

0 Likes
#18

Hey Will,

As previously stated, I’d be ok without automatic updates but even a manual refresh doesn’t work. So this isn’t simply SSHFS signalling. I can drop out to a Finder on OSX and see the changes instantly, only the sidebar in sublime seems to choke on changes 90% of the time. Even on respawn it’s sometimes slow to load what is already visible in Finder. Further to this I can ask Sublime to “Open” the file using the File menu and navigating to it, Sidebar would still not see it.

Aside from that I had used Expandrive in the past and found it very unreliable and not worth the money. That said I installed ver6 and tested it but it doesn’t help at all. Sidebar is still ridiculously slow to update even when manually triggered to do so. Seems much worse with Expandrive installed, which doesn’t use SSHFS but SFTP.

I’d be happy to try to fix this but I would need some hand holding to get me started.

0 Likes
#19

This seems very odd. When I was working on some symlink stuff in this dev cycle I learned some more about the implementation we have. We literally ask the OS to tell us the name of every file in a folder, and do that recursively.

Now granted, I found a bug in Expandrive that it returns different results to the posix function calls (which we use) and the NS Objective-C classes. My hunch is that Finder is using the Objective-C bindings, not he posix ones. Perhaps there is something going on there that the FS layer is just returning nonsense for opendir() and readdir().

0 Likes
#20

Does seem odd as a recursive request seems like it would just load. Does it do any comparisons while grabbing the new list? It just hangs indefinitely. I think I had tested that if I walk away for long enough it refreshes but it can take a long time (tens of minutes) for that to complete, where a restart of the app usually refreshes everything instantly.

If there is a debug mode or some out put I can send you to help please let me know.

0 Likes
#21

In my case, if I have a file in some directory and I save the file with command+s, it would trigger the located directory (and subdirectories under this) to be refreshed immediately. But this only holds after I started sublime for some time which I guess is because its doing some initialization stuff. Also I did observe that the refresh may happen secretly after a long wait.

My environment:
macOS 10.13.4
ST3 build 3170
OpenSSH_7.6p1, LibreSSL 2.6.2
OSXFUSE 3.7.1

0 Likes
#22

My hunch would be that the refresh is pushed into the queue, but it will happen after your entire file tree has been listed.

You should be able to identify folders being scanned by looking for an animation of dots in the folder icon. You can use the alt key and click on the arrow to recursively expand folders to see where it has made it to in the processing.

0 Likes
#23

A simple fix to this is to set the “refresh” from the folder the user has selected instead of the entire project. I understand that entire project would take time to refresh especially on a remote FS. But if we could just have the ability to only refresh the tree that is selected this would likely solve this problem.

0 Likes
#24

It’s unbelievable that this has not yet been solved in 2024.

0 Likes