| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | File Handles |
Original from Paul Edwards to Jonathan de Boyne Pollard on 12-11-1996
Original Subject: File Handles
---------------------------------------
JdeBP> For another, even if the device driver *could* make
JdeBP> application-level API calls to perform file I/O, there's no
JdeBP> guarantee that the process, one of its parents, will not have
JdeBP> closed the file handle concerned an possibly opened another one
JdeBP> in its stead. There are no "system" or
"reserved" file handles.
JdeBP> Each process is sovereign as far as its ope file handles are
JdeBP> concerned.
> But I don't agree with this. You don't have the right to close arbitrary
> file handles. You're only allowed to close files that you
> yourself have opened. That's a bit like saying that the
> device driver shouldn't rely on being able to access memory
> it just malloc'ed, because "the user might have run a
> program to go and deliberately clobber that memory".
JdBP> Wrong on both counts.
JdBP> First count : An OS/2 process can do what it likes with *any* of the
JdBP> file handles that it has open. There's *nothing* that stops it from
JdBP> closing any or all file handles that it has open. As far as its file
JdBP> handle table is concerned, each process is sovereign.
JdBP> Ever written a daemon process ? What's the first thing that a
JdBP> well-written background daemon process does ? That's right. It closes
JdBP> any open file handles that it may have accidentally inherited.
PE> Ok, so how do you do this properly? for (x = 0; x <
PE> ULONG_MAX; x++) DosClose(x);
PE>
PE> ??? And there's definitely nothing wrong with closing file
PE> handles that have NEVER been opened? And nothing wrong
PE> with closing a file handle which may have been fopen'd by a
PE> previous process, and still has data in the buffer, which
PE> needs to be flushed to disk?
Each process has it's own set of file handles. It can inherit open
handles from it's parent, but once it "has" them they are
"private" to
the process. The child process can close them with impunity and not
affect the parent process's handle to the same file in any way.
The "connections" to an actual file are:
application handle --> app JFN --> SFT -----+
application handle --> app JFN --> SFT --> MFT --> system file
application handle --> app JFN --> SFT -----+
When you close a handle, all you do is remove your application's JFN
and SFT entries. You do not affect any other application's access to
the file through it's handles.
You can just close all possible handles from 0 thru maxFH for the
process. I don't know how your compiler would handle it, but the
kernel will just return:
DosClose returns one of the following values:
0 NO_ERROR
2 ERROR_FILE_NOT_FOUND
5 ERROR_ACCESS_DENIED
6 ERROR_INVALID_HANDLE
You can obtain the max handles for your process with:
rc = DosSetRelMaxFH(&ReqCount, /* Using 0 here will return the
*/ &CurMaxFH); /* current number of file
handles */
Denis
All opinions are my very own, IBM has no claim upon them
.
.
.
--- Maximus/2 3.01
* Origin: T-Board - (604) 277-4574 (1:153/908)SEEN-BY: 270/101 711/401 409 410 413 430 808 809 934 955 712/407 515 624 628 SEEN-BY: 713/317 @PATH: 153/908 8086 800 270/101 712/515 711/808 934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.