Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: TOpenTextFileDialog locks the folder it opened


This question is answered. Helpful answers available: 1. Correct answers available: 1.


Permlink Replies: 6 - Last Post: Mar 7, 2017 1:27 PM Last Post By: Anders Andersson
Anders Andersson

Posts: 5
Registered: 10/30/06
TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 26, 2017 7:25 AM
It seems like TOpenTextFileDialog for some reason keeps a handle or such to the folder that contains the file it opened.
Repro:
- Create empty VCL forms application
- Add a TOpenTextFileDialog
- Add a button which opens the dialog in its Click function:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
	OpenTextFileDialog1->Execute(this->Handle);
}

- Start the application, click the button, select a file and press Open
Notice that the folder that contains the file that you just opened can't be removed or renamed using Explorer or similar ("The action can't be completed because the folder or a file in it is open in another program")

The file that you opened can be deleted however, just not its folder. TOpenDialog does not have this problem.
Known issue? Any workaround? Or am I missing anything?

I use C++Builder XE2, Windows 10.
Thanks.

Edited by: Anders Andersson on Feb 26, 2017 3:25 PM
Anders Andersson

Posts: 5
Registered: 10/30/06
Re: TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 1:54 AM   in response to: Anders Andersson in response to: Anders Andersson
Tried this too but still it locks the folder, can't seem to find any workaround.

void __fastcall TForm1::Button1Click(TObject *Sender)
{
	std::auto_ptr<TOpenTextFileDialog> openDlg = std::auto_ptr<TOpenTextFileDialog>(new TOpenTextFileDialog(this));
	openDlg->Execute(this->Handle);
}
Anders Andersson

Posts: 5
Registered: 10/30/06
Re: TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 6:25 AM   in response to: Anders Andersson in response to: Anders Andersson
Even worse!
I found out if I associate a file type with the exe of an empty VCL project and then double click this file -> my program opens -> the program does nothing, however the folder the file is in will now be locked for rename/removal!

Am I the only one getting this? Running Win 10, UAC off, XE2.
Remy Lebeau (Te...


Posts: 9,229
Registered: 12/23/01
Re: TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 11:14 AM   in response to: Anders Andersson in response to: Anders Andersson
Anders wrote:

I found out if I associate a file type with the exe of an empty VCL
project and then double click this file -> my program opens -> the
program does nothing, however the folder the file is in will now be
locked for rename/removal!

All the association does is allows the Windows Shell to execute your EXE
with a file path as a command-line parameter, nothing more. Your app must
be coded to actually read the command-line and open the file. The RTL/VCL
does not do that for you, you have to write your own code for it. The only
way the directory could be getting locked is if Windows Explorer itself,
not your VCL app, is locking the directory. Perhaps Microsoft has coded
Windows Explorer with some smarts to recognize that your EXE gets launched
with a file path and locks the directory from changes until your app exits.
Who knows. Either way, it is not the RTL/VCL doing the locking. Use a
tool like SysInternals Process Explorer to see exactly which process is actually
locking the directory.

--
Remy Lebeau (TeamB)
Anders Andersson

Posts: 5
Registered: 10/30/06
Re: TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 12:01 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
All the association does is allows the Windows Shell to execute your EXE
with a file path as a command-line parameter, nothing more. Your app must
be coded to actually read the command-line and open the file. The RTL/VCL
does not do that for you, you have to write your own code for it. The only
way the directory could be getting locked is if Windows Explorer itself,
not your VCL app, is locking the directory. Perhaps Microsoft has coded
Windows Explorer with some smarts to recognize that your EXE gets launched
with a file path and locks the directory from changes until your app exits.
Who knows. Either way, it is not the RTL/VCL doing the locking. Use a
tool like SysInternals Process Explorer to see exactly which process is actually
locking the directory.

I hear you, that would make sense, and maybe the most likely explanation is Windows doing some funky business, however, Process Explorer does indeed point out my VCL app.
Repro:
- created an entirely empty VCL project and just compiled it to get an exe.
- created a folder "e:\test" and a file in that folder which I associate with my newly created project "Project2.exe"
- double click the file and the folder can no longer be removed/renamed
- Process Explorer -> Find handle, search for "e:\test" shows my Project2.exe and nothing else
- Associating the file with any other non VCL app does not lock the folder.

Really odd... would be interesting to know if it is something local for me or if anyone else gets it. Thanks for your time.
Remy Lebeau (Te...


Posts: 9,229
Registered: 12/23/01
Re: TOpenTextFileDialog locks the folder it opened
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 1:07 PM   in response to: Anders Andersson in response to: Anders Andersson
Anders wrote:

Repro:

Reproduced on Windows 7.

However, what you describe is not the RTL/VCL at fault, as it *DOES NOT TOUCH
THE FOLDER* at startup. This is easy to verify - simply run your same EXE
from code using the Win32 API CreateProcess() function, or at least run the
EXE from the IDE using the project's "Parameters" option. Either way allows
you to pass the file path to your app's command-line, just like the Registry
association does. Running the EXE this way, the folder does not get opened.
So it can't be the RTL/VCL opening it.

Only when clicking on a registered file in Windows Explorer, or running the
registered file via the Start Menu's "Run" command, does the folder get opened
within the VCL process.

Using SysInternals Process Monitor shows a call to CreateFile() being made
inside the VCL process to open the folder, and a matching call to CloseHandle()
at process close. But only when the EXE is launched by clicking on a registered
file, or when running a registered file directly.

I cannot find anything in the RTL/VCL source code that calls CreateFile()
(directly or indirectly) at process startup, let alone on a path that is
passed via the command-line.

Thus, the Windows Shell is clearly causing the behavior. My first guess
is the Shell knows it is launching a registered EXE, so it opens the target
file's folder beforehand and that handle then gets inherited by the started
EXE. But that would not explain why Process Monitor shows the EXE calling
CreateFile() at startup, unless that is how Windows implements handle inheritance
behind the scenes (I have no idea). Bu I can definately confirm with the
debugger that the RTL/VCL is not the one calling CreateFile() at process
startup.

- Process Explorer -> Find handle, search for "e:\test" shows my
Project2.exe and nothing else

For me, Process Explorer shows the folder open as a "File" within the VCL
process's list of open handles, however "Find Handle" does not find it in
that process at all, it finds it (twice!) in the Windows Explorer process
only.

--
Remy Lebeau (TeamB)
Anders Andersson

Posts: 5
Registered: 10/30/06
Re: TOpenTextFileDialog locks the folder it opened  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 1:27 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Alright, thanks for looking into it, a bit annoying behavior by Windows and peculiar that we get slightly different behavior but I guess Windows works in mysterious ways.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02