TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Paul Edwards
from: Denis Tonn
date: 1996-12-19 09:24:00
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™.