SciTE maintains locks on files already closed?

98 views
Skip to first unread message

Andy Sy

unread,
May 2, 2020, 5:53:47 PM5/2/20
to scite-interest
Something I've noticed with SciTE from way back is that
even when you've closed a text file, it still seems to
be locked/considered open by Windows. (No idea with Linux
or MacOS)

For instance, you will get a warning when trying to
eject a flash drive with a text file in it that was
recently opened with SciTE (but now already closed),
*** as long as SciTE is still running ***.

You will need to exit SciTE completely if you don't
want to trigger the warning. Similar behavior with other
operations which also give warnings if a file is considered
still in use by Windows.

Neil Hodgson

unread,
May 2, 2020, 6:09:03 PM5/2/20
to scite-interest
Hi Andy,

> For instance, you will get a warning when trying to
> eject a flash drive with a text file in it that was
> recently opened with SciTE (but now already closed),
> *** as long as SciTE is still running ***.

SciTE never deliberately locks files. What is likely occurring here is that the Win32 Open File dialog sets the current directory of the process to the directory that it was last viewing. Windows then refuses to delete the current directory.

Neil

Andy Sy

unread,
Nov 12, 2020, 3:06:24 PM11/12/20
to scite-i...@googlegroups.com
So this problem seems to manifest in worse ways than I even
originally noticed.

In this particular case, SciTE is now completely closed and
no longer running in memory at all. I tried to unmount drive
L: (it is a Veracrypt volume) and Veracrypt is complaining that
a text file in drive L:\WinSCP\ that I earlier opened with
SciTE is still in use.

Shown in the attached screenshot are the file handles that
Process Explorer says are still in use. In order to release
these, I had to kill/restart the explorer.exe process.

Any idea what could be going on?
procexp-scite.png

Neil Hodgson

unread,
Nov 12, 2020, 4:23:28 PM11/12/20
to scite-i...@googlegroups.com
Andy Sy:

> In this particular case, SciTE is now completely closed and
> no longer running in memory at all. I tried to unmount drive
> L: (it is a Veracrypt volume) and Veracrypt is complaining that
> a text file in drive L:\WinSCP\ that I earlier opened with
> SciTE is still in use.

I can’t see any way for SciTE to produce an individual locked file itself. To open a file SciTE calls _wfopen(name, “rb”) followed by fclose(). There’s no lock call or similar.

To fix the directory open for the file open dialog issue, it might be possible to change the current directory to a safe place after any invocation of GetOpenFileName but that would require a well defined safe place. A naive approach could try the root directory of C: but that may not be valid when there is no C: disk or the user is restricted to a particular subdirectory.

Neil

holt...@gmail.com

unread,
Nov 16, 2020, 1:06:59 PM11/16/20
to scite-interest
Hi

I have noted this problem (windows 7/8/10) and have just tried this solution in my Lua startup script:

  function OnClose()                      -- CD SciteDefaultHome on close
    os.execute("setx CD "..props["SciteDefaultHome"])
  end

This expects SciteDefaultHome is a safe place.

The only down side is a 2-3 second pause. I assume CMD.exe updates the registry and sends the refresh signal, then windows explorer refreshes itself.

Does anyone know of a quicker way accessible from Lua?

Kind Regards Gavin Holt

Giuseppe Corbelli

unread,
Nov 17, 2020, 2:17:23 AM11/17/20
to scite-i...@googlegroups.com
%HOMEDRIVE%%HOMEPATH% should be always accessible, right?

--
Giuseppe Corbelli

michal.lip...@gmail.com

unread,
Nov 22, 2020, 4:02:08 PM11/22/20
to scite-interest
We have encour the same problem.
CASE 1:
STEP BY STEP EXAMPLE:
1. Open first/single/empty SciTE.exe instance
2. using menu File open file any file
3. close  the file opened in SciTEWindow , but do not close SciTE
4 you will notice that there is NO issue with deleting file parent directory 

CASE 2:
STEP BY STEP EXAMPLE:
1. close all SciTE.exe instances
2. opne file from WindowsExplorer with using your mouse (double click).
3. close the file opened in SciTEWindow , but do not close SciTE
4.  you will notice that EXIST issue with deleting file parent directory 

SUMMARY:
When you in WindowsExpolorer open document assigned to SciTE then SciTE change current/working directory to the file parent directory.
And you would not be able to delete this directory even if you close this file in SciTE (with staying SciTE alive)

This is because SciTE after closing opened file should automaticaly change Current/Working Directory to the next file opened/acitve in SciTE and in case when there is no more opened documents/files in SciTE but in situation when SciTE is still working, then in time when SciTE close the latest file He(SciTE) should change Current/Working Directory  to parent directory of SciTE.exe file.



The better solution is to change SciTE behavior to change 


Jos

unread,
Nov 23, 2020, 8:30:38 AM11/23/20
to scite-interest
I've done some testing and added this line to function  WinMain() in SciTEWIn.cpp which sets the current directory back to the SciTEPath at startup for Windows:
[code]
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, int) {
// Set the current directory always to the program directory to ensure a opened file directory is never locked.
SetCurrentDirectoryA(GetSciTEPath((FilePath)nullptr).AsUTF8().c_str());
[/code]


Op maandag 16 november 2020 om 19:06:59 UTC+1 schreef holt...@gmail.com:

Neil Hodgson

unread,
Nov 25, 2020, 5:36:26 PM11/25/20
to scite-interest
Jos:
SetCurrentDirectoryA(GetSciTEPath((FilePath)nullptr).AsUTF8().c_str());

   That technique may be OK.

   Its unlikely that the directory of the application would disappear. Back in the olden times when floppy drives were in use, it used to be common to swap the floppy that an application started from with a data disk and the (fully loaded into memory) application kept running. That may not be possible anymore.

   I'll look at this some more after 5.0.

   For safely dealing with non-ASCII directory names, its better to perform file operations in wchar_t whenever possible so:
GetSciTEPath(FilePath()).SetWorkingDirectory();

   Neil

Jos

unread,
Nov 26, 2020, 8:29:29 AM11/26/20
to scite-interest
Neil Hodgson:
Back in the olden times when floppy drives were in use, it used to be common to swap the floppy that an application started from with a data disk and the (fully loaded into memory) application kept running. That may not be possible anymore.
I remember the floppy era well, even worked with punched cards :-) , but agree it should be save to set the default to the program path.
Thanks for the alternative (will have a play with that) and looking at it after the v5 release. 

Jos

Neil Hodgson

unread,
Apr 14, 2021, 5:41:56 AMApr 14
to scite-interest
Jos:

> I've done some testing and added this line to function WinMain() in SciTEWIn.cpp which sets the current directory back to the SciTEPath at startup for Windows:

This was almost committed earlier today but I started to think about what can go wrong.

The first problem is interpreting command line arguments that are relative paths rather than fully qualified paths. So the SetWorkingDirectory is now performed after processing the command line arguments.

The next problem was when check.if.already.open is set and a new instance of SciTE talks to the already running one. It asks for the current directory to be changed then sends the command line over. Command lines can be complex with relative paths used in different ways so it would be difficult to absolutize all potential paths. To fix that, a third message is now sent to the already running SciTE telling it to set the working directory somewhere safe again (setdefaultcwd).

After these updates, a change set was pushed:
https://sourceforge.net/p/scintilla/scite/ci/168ab23ac5e7de1bf5aad7cabda2b7cac0f5785b/

Since there were some non-obvious problems fixed, there’s a good chance there are more problems so Windows users should watch out for unexpected directory issues and should report any directory locking problems with this code.

Available from the Mercurial repository and
https://www.scintilla.org/scite.zip Source
https://www.scintilla.org/wscite.zip Windows executable (64-bit)

Neil

guit...@gmail.com

unread,
Apr 22, 2021, 9:14:11 PMApr 22
to scite-interest
seems SciTE 5.0.2  has fixed this issue.
Reply all
Reply to author
Forward
0 new messages