Deleting folders from sidebar fails if files in a sub directory were open #2403
Comments
|
I did some further investigation about it and it looks like there is an unclosed folder handle causing the issue. What did I do? Using ST vanilla install I added the TIM folder as in the screenshots above. After indexer is done, the OpenFile and CloseFile operations of the folder are still in balance, so we can delete the folder. 5.665 opens/closes
If I open one of the xml files and close it again SysInternals Procmon shows the following stats.
Looks like one directory handle is still open as CloseFile was not called for it. As a result the parent folder |
|
That's definitely interesting, in my case, I've arrived to this situation where a folder got locked, here's the unlocker report after making sure all external processes are not using this folder and also made sure the And yeah, procmon will tell me the open/closes are not balanced: Anyway, I'm trying to figure out how to use psutil to: 1.- Report the same information than the one provided by unlocker Btw, one comment in the SO thread I've opened related to this issue pointed out that before deleting the folder would be convenient to level-up one directory before trying to delete the folder, that makes sense... although I've tried manually |
|
Btw, thanks to bring up to the table procmon, it's a really interesting tool, it allows you to create really nice filters, so for instance, I'm having problems with that folder and sublime_text process, so I can export the csv such as: Which is cool, but I'm still trying to figure out how to get more information about the "handles" reported by unlocker, that's the really interesting stuff here to know which part of the processs has locked the file/folders... :) |
|
The SysInternals Progcess Explorer shows the number of open handles per app, too. I saw the number of open handles constantly increasing in ST after each file open operation. Unfortunately it doesn't tell much about the type of handles not being closed anymore. Maybe files, maybe other controls. |
|
posted a partial solution on the forum, I did so in case will reach more people interested on this issue |
|
I am encountering this as well on Windows and its quite annoying. I can't even git-clean sometimes without first exiting Sublime due to it leaking file handles. Any word on a proper fix? |
|
The best way I can think of would be having a background service or web_server running in non-visible mode with admin privileges, such service would allow you to unlock folders. You'd need to run this service at startup so it wouldn't prompt the UAC dialog. Why admin mode? Well, if you want to unlock folder/processes you definitely need admin privileges to do, so either you run ST3 as admin or even worst, you run ST as normal user and make your code to prompt the UAC elevation privileges dialog, this last would be really annoying cos this UAC dialog would bother you over and over each time you wanted to unlock folders. Of course, the above proposal is not ideal (if you were coding a service) cos as you know, writing windows/mac/nix services is non-portable stuff, you'd end up having a non-portable solution. So yeah, I understand why ST core devs didn't put any effort on this issue... guess was mainly because it needs admin requirements, that would bother end-users at the end of the day... or maybe they didn't give a ... who knows :) Ps. But yeah, I do agree with you, this limitation is really annoying. Said otherwise, can't you delete folders? So why are you providing your users with a mediocre solution such as "Delete Folder"... if you're providing uncomplete solutions it's better don't ship them at all. Easy peasy :/ |
|
The issue still exists in build 3180. It seems the bug appeared in build 3175/3176? |
|
It seems it exists in 3174. I'll try 3173. |
|
I think I am seeing this build 3176, with opening a file on usb storage, closing the file, and then SublimeText still has an open handle on the folder the file was in. I'm not even opening the entire folder in SublimeText. It may be related to where Sublime Text expects the File->Open dialog to start at, but it seems like bad behavior. I currently have to use ProcessExplorer to kill the specific handle OR completely close SublimeText. |
|
I wish this issue got addressed, had to abandon Sublime Text 3 because of it and because of issued caused by forcefully closing file handles. Some repositories are huge with millions of files, having to restart Sublime Text because it decided to lock a file that is not open in any way makes for an extremely frustrating experience, having this happen several times per day, just by viewing a file (with indexing and everything else off) and trying to rename the directory afterwards only to get an error got to a point where it was practically ridiculous. |
|
This issue is fixed in ST 3189 |
|
Bug is still there (build 3211) Windows 10. |
|
This issue has never been fixed properly... i recall when we were discussing about it few months ago i'd created some little tcp server so when some folder couldn't be deleted sublime send some request to it to unlock the folder... but it was a pain in the ass to run it, admin rights, etc... This has been a really pita of sublime for ages... deleting folders is really challenging... I don't understand why you said has been fixed in 3189... the bug still remains in (build 3211) windows7... |
|
This issue is about opening a file in ST causing the containing folder(s) to be locked by Windows forever - most likely because of leaking file handles - which caused OSError 120 when trying to delete one of the parent folders. This was a painful issue in ST3176 which is definitly fixed. ST of course has no control about other applications locking files and folders. What you might most likely be running into with build 3211 is #3124 |
|
@deathaxe Oh, ok... I didn't know that... in my previous comment maybe i've extracted conclusions too fast, so sorry about misleading there. And yeah, thanks to reference the other issue here. I'll be definitely paying attention from now that's certainly the case. |
|
You can't say that it is fixed, the original issue might have been fixed however you should note that |
|
This issue was fixed. A similar but distinct bug affects some users. It doesn’t help anyone to keep any bug with a similar symptom open until every bug is fixed. |
Summary
This issue report is the result of a discussion at https://forum.sublimetext.com/t/sublimetext3-cant-delete-folders-from-side-bar-on-windows-very-often
It looks like ST locks the folder of a file it opened on Windows OS. As a result the parent folder can't be moved to the recycle bin via
SHShellFileOperationwhich is used by thesend2trashpython module. Deleting the folder via Windows Explorer fails, too.SHShellFileOperationreturns error code 120.Expected behavior
It should be possible to remove all (parent) folders even if a file within them is still open in a view. In many other cases if a file is deleted, the view still contains the content and marks the file modified. Same should happen if one of the parent folders is deleted - no matter which level.
Actual behavior
The following screen capture shows a command prompt script creating the folders and the xml/html files within the
hlpfolder. If none of the files is opened in a view, the whole folder tree starting withhlpcan be deleted successfully.But as soon as one of the files was open in a view - even for preview only - the folder
hlpcan't be deleted directly. Neither by sidebar nor by Explorer.One must delete the folder which contains the open file manually (
deuin this example). In worst case this means the whole folder tree needs to be deleted by picking each folder one after another by hand - depending on the previously open files.Steps to reproduce
folder 1to the sidebar of ST (vanilla install)file.xmlfile.xmlfolder 2-> failsfolder 3-> worksfolder 2again -> worksEnvironment
dpi_scaleused in ST 1.0The text was updated successfully, but these errors were encountered: