When the Sublime Text Updater tries to download the latest update on the install step I run into an error message that says:
“Unable to rename C:\Program Files\Sublime Text 3 to C:Program Files\Sublime Text 3 (3143), acess denied to src path”
I tried running Sublime in Administrator Mode and I got the same error.
Sidenote: ‘acess’ was indeed misspelled on the error message
have you tried manually downloading the full installer for the latest version instead of relying on the auto updater?
That did update it yeah, any idea on why the built in updater/installer wouldn’t work though?
Windows is pretty eager to lock things on the filesystem, that combined with ubiquitous virus scanner usage can lead to the virus scanner locking files and folders while it is checking what is going on. This can lead to failures. That would be my guess.
It’s been 5 years and that issue is already here.
I think it’s a very critical way to convert sublime text users to other platform 
I try several times, i’m stuck to the build 4107.
I’ve always written this off because I could just download the installer from the ST website, but now that my company blocks downloads from ST as potentially malicious, the updater is my only way to get the latest versions and that doesn’t work because it’s trying to rename something in Program Files (which it doesn’t have access to perform). Does this renaming really need to happen? Maybe there could be a checkbox added to the Update modal asking if we want to allow for rollback (or whatever this is for) or a configuration setting? Basically, is there any way to get past this issue? I’m not excited about being stuck on my current version forever… But of course, getting that change would require me to download a new version, which I can’t do, so, looks like I might be SOL. 
Sublime Text is (usually) installed in Program Files. Renaming is how updates have always been installed.
I think in the past one of the reasons this happens is if you’re using a package that executes an external program that is launched by the plugin host, which stops the plugin host from stopping, which locks the directory.
I’ve never tried it myself, but if you’re using ST4 it might be possible to start Sublime in safe mode and update it from there, which could potentially get around that (if that’s the problem).
Sublime Text is (usually) installed in Program Files. Renaming is how updates have always been installed.
Yup, and I’ve never been able to successfully update using the updater.
Tried starting in Safe Mode, but I’m still getting this: 
Did you make sure to close all other instances of Sublime Text before starting safe mode? You could try finding out which process has that folder open: https://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows.
I closed all but the instance with the update installer modal. It’s still failing, though, and I don’t see any suspicious open handles. The only thing that’s remotely noteworthy is that the command line for the update installer itself is originally run from \Program Files\Sublime Text\update_installer.exe but the update installer itself lives in AppData, so doesn’t seem like an issue.
You should be able to see all open handles and filter for the one that has C:\Program Files\Sublime Text open. That’s what’s blocking the update.
Finally got the update to work. I had to manually kill off the plugin_host process and jscomma.exe. I also saw TabNine in there, but I think that died with plugin_host. I wonder if the issue was that TabNine was keeping plugin_host alive. Anyway, it’s done, thanks for the help. 
Wanted to add in case anyone else faces this issue, File Locksmith is a tool included in Microsoft PowerToys that makes finding out which processes are using a file or directory very easy.
