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.
| Вернуться в корень Архива |