CreateProcess and file handles
Matthias Bohlen -- MATTES@logotec.com
Wednesday, August 07, 1996
Environment: Visual C++ 4.0 / Windows NT, Windows 95
On 3 Aug 96 at 19:09, Jason R. Simpson wrote something about CreateProcess
and input focus.
When talking about CreateProcess ... (slightly off-subject here because
this is an MFC discussion list - I apologize) ... let's mention a bug in
Windows 95 (maybe MS can fix it).
If you create a process while you have still a file open, the handle of this
file is inherited by the child process (i.e. the child process can use the
file using this handle). That means, as long as the child process is
running, you cannot successfully close, delete and re-create the file.
This is true for CreateProcess() and it is true for WinHelp(). The latter
starts WINHLP32.EXE which inherits the file handles (very nasty thing).
Normally, when you open a file with CreateFile(), you can specify whether
the created file handle is inheritable or not (using a security
descriptor). Under Windows NT 3.51, that works perfectly, under Windows 95,
it does not. The child process always inherits the handle.
Normally, when you call CreateProcess(), you can also specify whether the
created child process should inherit file handles or not. Again, under
Windows NT 3.51, that works perfectly, under Windows 95, it does not. The
child process always inherits the handles.
Maybe, MS can do us all a favor and eliminate this bug in Windows 96 :-)
Matthias Bohlen
P.S.: Does anyone know whether CFile::Open() uses a security descriptor in the
call to CreateFile() ?
o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
The ZEN master: "If you have a stick, I'll give you a
stick. If you have not, I'll take that stick away from
you".
The banker: "If you have money, I'll give you money.
If you have not, I'll take that money away from you".
----------------------------+--------------------------
Matthias Bohlen | Logotec Software GmbH
Phone: +49 228 64 80 520 | Chateauneufstr. 10
FAX: +49 228 64 80 525 | D-53347 Alfter, Germany
| http://www.logotec.com/
E-mail: mattes@logotec.com | CAD systems development
----------------------------+--------------------------
Mike Blaszczak -- mikeblas@nwlink.com
Saturday, August 10, 1996
At 09:25 AM 8/7/96 MET, you wrote:
>If you create a process while you have still a file open, the handle of this
>file is inherited by the child process (i.e. the child process can use the
>file using this handle). That means, as long as the child process is
>running, you cannot successfully close, delete and re-create the file.
> [...]
>The child process always inherits the handle.
Really? Even if you pass FALSE for the bInheritHandles
parameter to ::CreateProcess()?
> That means, as long as the child process is running,
>you cannot successfully close, delete and re-create the file.
I can't reproduce that behaviour. At least, I can't reproduce that
behaviour in situations where I don't expect it.
> Normally, when you open a file with CreateFile(), you can
> specify whether the created file handle is inheritable or
> not (using a security descriptor). Under Windows NT
> 3.51, that works perfectly, under Windows 95,
> it does not. The child process always inherits the handle.
The VC++ C Runtime manipulates a security descriptor, specifically
setting the inheritance flag to match what you requested when
you opened the file. (See the file MSDEV\CRT\SRC\OPEN.C for
this code.) Maybe you're not setting up the security descriptor
correctly.
Using "stdio" C runtime files, it's trivial to show that you can
open a file, spawn a process with CreateProcess(), and write and
close the file freely from the parent process while the
child continue to run... even under Windows 95.
If you're experiencing this behaviour, maybe you should post a
reproduction case.
>P.S.: Does anyone know whether CFile::Open() uses a security
> descriptor in the call to CreateFile() ?
Yes: anybody who's looked at the source code (in
FILECORE.CPP in the MSDEV\MFC\SRC directory) knows.
.B ekiM
http://www.nwlink.com/~mikeblas/
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|