Sublime Forum

Bug: Sublime holds lock on file even after file is saved and closed


Windows 10 Enterprise (x64), version 1803, build 17134.407
Sublime Text 3, dev channel, build 3184

Sublime Text keeps some sort of lock on files, even after I close the file. The lock is not released until I close Sublime completely.

Steps to reproduce:

  1. Insert a USB drive with a text file on it.
  2. Open the text file in Sublime Text. Make a change and save the file.
  3. Close the text file, but keep Sublime Text open. (My setup has a “project” unrelated to the files on the USB drive.)
  4. Attempt to safely eject the USB drive – this will fail. (“USB Drive (D:) is currently in use.”)
  5. Close Sublime Text completely.
  6. Attempt to safely eject the USB drive – this will succeed.

Is this expected behavior?

1 Like

Bug: Busy files on Windows screws up Git

I tried to find a issue reporting this on the issue tracker but I think I could not find one exactly like this. You could open a new issue reporting this on




Thank you for pointing me to the issue tracker. I’ve posted a new issue.



Just for reference, this was fixed in build 3189



This is still happening to me by the way, I just got screwed on an interactive git rebase again (I’m using sublime as my git editor). I’m on the latest version as of today.



See the “Permission denied”. I had just finished editing in sublime during the rebase, when I did git rebase --continue, I get this error. Incredibly frustrating, and I paid money for this thing.

$ git commit --amend -C HEAD
[detached HEAD 63159090] Dispatch basic_stream::close
 Date: Tue Feb 26 16:10:51 2019 -0800
 2 files changed, 30 insertions(+), 3 deletions(-)

vinnie@VF-Corsair MINGW64 ~/src/boost/libs/beast (v222|REBASE-i 6/7)
$ git rebase --continue
CONFLICT (content): Merge conflict in
error: failed to open '': Permission denied
hint: Could not execute the todo command
hint:     pick 1c3668422cc103f17c8b78e38779c1413446681e websocket stream dtor closes the lowest layer
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint:     git rebase --edit-todo
hint:     git rebase --continue
Could not apply 1c366842... websocket stream dtor closes the lowest layer

vinnie@VF-Corsair MINGW64 ~/src/boost/libs/beast (v222|REBASE-i 7/7)


Problem still exists as of 3190

Let me be crystal clear here, the problem is definitely with Sublime text. I switched to VS Code for a few weeks and the problem went away, with the exact same workflow. Sublime editor is much nicer than VS Code and when I saw this bug was claimed to be "fixed’ in Sublime, I switched back. Unfortunately, the problem came back.

What happens is for example I do an interactive git-rebase, reorder some commits (using sublime as the git editor), and edit a file during the rebase. Then when I try to continue the rebase I get the permission error on the exact file that I edited. This, after closing the file.

I can work around it by exiting Sublime text. When I exit Sublime before continuing the rebase, the problem NEVER happens. So I have extreme confidence the problem is with Sublime.

I also tried one other shitty editor, I forget the name, and it did not have this problem but it was so bad I had to switch.



Sublime Text doesn’t, and never has, opened files in an exclusive mode on Windows. The issue referred to above was holding onto a handle for the containing directory for too long, which prevented the directory from being deleted.

I strongly suspect it’s another program entirely that is tripping Git up here.



I’m not sure if this is the same issue, but I’ve got sublime set as default editor in git and sometimes when I do interactive rebase, the commit will not save until I close sublime completely.
Sometimes it works exactly as I want it though - the commit is saved when the tab with commit file is closed.



You are probably talking about the issue below, which has supposedly been fixed in the latest build.

1 Like


No clue if this bug has been addressed properly on latest SublimeText versions but few months ago when trying to fix it by myself the only solution it happened to me was to create my own “unlocker” (simple server wrapping awesome Mark Russinovich handle). Basically when trying to delete some locked folders SublimeText will send a request to my unlocker and the folder would be deleted.

Of course, this solution is not ideal as you need:

a) have handle.exe available in your system
b) it’s not a multiplatform solution
c) you need to run this “unlocker” server as admin… which i found to be problematic if trying to spawn it as a windows service (daemon)

That said, I’d hoped this nasty bug would have been solved properly by core devs in future versions of Sublime… not being able to delete folder at any time is a really nasty and very annoying BUG



Have you tried to see if your fix is still needed? Both of the original issues noted at the top of this thread (which I think refer to what you’re talking about here) where closed and reported as fixed in build 3189. I was having the same problem on Windows and it was resolved for me by those fixes.



For what it’s worth, the actual bug that I filed on GitHub was specific to files opened from a USB drive on Windows. For that specific scenario, I can confirm that the fix works. I have not experienced the problems as described by others in this thread.

I have, however, noticed that bash on Windows holds locks on folders pretty aggressively. To the others in this thread, if you’re using bash on Windows, I suggest you try to reproduce the bugs you’re experiencing without bash running in the background.



Do you have any plugins installed in ST? Especially those which work with git? Maybe GitGutter, GitSavvy, … ?

Some of them call git in the background if the file content of an open file changes during the rebase operation. This may cause a second git instance to try to access the file in the background while it is modified by your rebase operation.

Btw.: I’ve seen such “permission denied” issues in the past as well during heavy git rebase -i operations. Didn’t do such big git rebase stuff since then.



I have no plugins and i don’t use scripts. I only use Sublime as a text editor, mainly because it is very fast and renders crisply, and has an excellent folder explorer on the left side. I do have the folder explorer open all the time. My git rebase is not heavy at all, I just typically move a commit a few places back and then fix the merge conflict on my file. This is where I get the Permission denied. Doesn’t happen with any other programs, and doesn’t happen if I exit Sublime after editing the file.

I am using the bash that comes with git. However, I never experience this issue unless Sublime is running at the time I issue the git rebase --continue.



Just to update on this issue. It would appear that Git on Windows may not be properly checking to see if a file is ERROR_DELETE_PENDING if Sublime Text has allowed a file to be deleted, but is not done with the file handle itself. I tried searching through to see if the Git codebase deals with that, but couldn’t find any evidence of that. You can read more about the error code at

We’ve made a change to the indexer in build 3193 that releases the file handle as quickly as possible, so hopefully it should work around the issue.


Bug: Busy files on Windows screws up Git

Thank you very much for looking into this. I’ve downloaded the new version and I’ll report back after some time with it. I still wonder why this isn’t happening with other editors. What is the “indexer?”



The indexer is a background process that scans your code to find class and function definitions. It powers the Goto Definition / Goto References functionality, along with the Definitions / References popup.

There likely reason is a combination of various implementation details of Sublime Text. We use syntax definitions that are optimized for performance. When a syntax definition (such as Markdown) includes another syntax definition (such as CSS, for fenced code blocks), it must copy the embedded definition to allow for the highest performance when highlighting files. The Markdown syntax, since it is used with all sorts of languages, supports highlighting a whole bunch of syntaxes within fenced code blocks. Including all of these increases the size of the cached syntax definition on disk.

When the indexer runs, it loads the cached syntax definition into memory and uses it to highlight a file. Once the file is highlighted, it can use the scope information to find function and class definitions. The first time it runs into a file of a specific type, the cached definition has to be loaded into memory. If the cached syntax definition is large, it is possible based on the speed of your hard drive that it make take a short while to load the syntax definition.

Now, for the best performance with files, we incrementally load the file contents as we syntax highlight it. This is because the IO of loading and CPU usage of highlight don’t compete. So, previously we believe you were running into a situation where you would:

  • Git would change a markdown file as part of your process
  • Sublime Text would see the file changed
  • It would create an indexer background process to look for definitions
  • The indexer would open the file and start reading, and at the same time load the syntax definition and start highlighting
  • Since the Markdown definition is large, it would take a little while to load
  • During that time, Git would delete the file (and the way we open it, that would be fine, no errors)
  • Next, we’d continue loading the file and syntax definition while the file was in a pending delete mode
  • Git would try to recreate the file during the rebase, but would get back an error indicating the file was in pending delete mode and would print an error to you

For the indexer, we’ve revamped the loading and highlighting process to load the entire file into memory as quickly as possible and then close the file handle. Then we load the cached syntax definition and do our work. This change is acceptable since the indexer doesn’t display the file to the user, so a slight decrease in overall performance isn’t really a regression, especially if we can sidestep issues with other software. Hopefully this reduces the amount of time we have a file handle open, effectively working around the issue that Git wasn’t waiting for the pending delete to complete.



Thank you very much for this detailed explanation! No wonder I keep coming back to Sublime Text…it performs quite well.

This explanation is actually quite helpful. My is modified in almost every commit: to add a line describing what was changed. I do interactive rebases a lot to fold commits and reorder them, and the change log file normally has conflicts, which I bring up sublime to resolve (usually already running). And when I continue the rebase that’s when I get the permission error. This accounts for why is always the one getting the error even though there are other files that I might have edited during conflict resolution. To be clear, I have never seen this happen on any file other than

I don’t actually use Go To definition or any symbol features, although I do like the syntax highlighting. However, I don’t really need the syntax highlighting in my markdown file, so turning it off would not impair me.

I have set `“index_files”: false will this resolve it?




I would try running build 3193 and hopefully you shouldn’t see the issue again.

You are certainly welcome to turn off the indexer, but personally I’d recommend trying out the Goto Symbol in Project functionality at some point. It can really make it quite easy to jump around a project without having to mentally map code to files and them using the Goto Symbol within the file to jump to it.

1 Like