cwong@charlie.coyote.trw.com (Chun Wong) (02/26/91)
Can someone distinguish the differences between a file descriptor and a file handle? I know that creat returns a file handle whereas fopen returns a file descriptor. What's the difference? Are they interchangeable? -C. Wong
campbell@dev8n.mdcbbs.com (Tim Campbell) (02/26/91)
In article <27C9CB35.5F7@wilbur.coyote.trw.com>, cwong@charlie.coyote.trw.com (Chun Wong) writes: > Can someone distinguish the differences between a file descriptor and > a file handle? I know that creat returns a file handle whereas fopen > returns a file descriptor. What's the difference? Are they interchangeable? > > -C. Wong -- I'm reciting this from memory - I haven't had to use it in a while so if I get these mixed - somebody please post the correction. File Descripters vs. File Handles - Applies specificly to DOS (MS-DOS, IBM-DOS, etc.) based applications. File Descripters were a carry over from CP/M - when a program needed to open a file, it created a block of memory in it's own data area which contained the necessary information about the file. - Most importantly, was the location of the file. In contrast, File Handles are more "true" to the nature of the OS, because instead of forcing the program to track info about the file it is using, it merely requests that the OS open the file and give it a "handle". The OS is then responsible for all the details of file maintenance (knowing where the file is, etc..) The program only needs to request that the OS perform some function on the file attached to some specific "handle". File handles are the better way to go. When hard disks were 10Mb and had a 12bit FAT table, the machine required 1 word (2 bytes) to contain the info in the file descripter. When DOS 3.0 showed up and hard disks could become larger (20Mb+) the FAT table became 16bits and the 1 word of storage in the file descripter was still sufficient to handle the job. Then DOS 4.0 showed up and the fat table format increased beyond the ability of the file descripter to safely track files which went beyond the 32Mb location on the disk. (This is why you should run SHARE on disks with > 32Mb partition sizes - SHARE intercepts these old programs still using file descripters and helps them find their data - without SHARE, your program could read or write data at an incorrect location.) If you rely on handles - (IBM stated this YEARS ago), you will never need to worry about how your program will perform when operating systems are upgraded. Hope this helps. -Tim --------------------------------------------------------------------------- In real life: Tim Campbell - Electronic Data Systems Corp. Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA also: tcampbel@einstein.eds.com @ EDS - Troy, MI CompuServe: 71631,654 Prodigy: MPTX77A P.S. If anyone asks, just remember, you never saw any of this -- in fact, I wasn't even here.
jik@athena.mit.edu (Jonathan I. Kamens) (02/27/91)
In article <27C9CB35.5F7@wilbur.coyote.trw.com>, cwong@charlie.coyote.trw.com (Chun Wong) writes: |> Can someone distinguish the differences between a file descriptor and |> a file handle? I know that creat returns a file handle whereas fopen |> returns a file descriptor. What's the difference? Are they interchangeable? First of all, creat is obsolete. :-) Second, creat returns a file descriptor, not a file handle. If your manual claims that it returns a file handle, then it's out-of-date. The reason I say "out-of-date" instead of "wrong" is that I have heard file handle and file descriptor used interchangeably in the past, but it's probably a bad idea to use them that way nowadays, becavuse "file handle" has taken on a very different meaning in some circles. For example, the NFS people use the term "file handle" to refer to the widget used to represent a particular file on an NFS server in communications between NFS servers and NFS clients. Hence you might get the error "stale NFS file handle" if you cd into an NFS directory on a client machine, then delete the directory on the server, then try to do a "pwd" or other operation on the directory in the client. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
sarima@tdatirv.UUCP (Stanley Friesen) (02/27/91)
In article <27C9CB35.5F7@wilbur.coyote.trw.com> cwong@charlie.coyote.trw.com (Chun Wong) writes: >Can someone distinguish the differences between a file descriptor and >a file handle? I know that creat returns a file handle whereas fopen >returns a file descriptor. What's the difference? Are they interchangeable? A file handle (as you call it) is a small integer used by the operating system (MS-DOS?) to access the file state, and allow it to perform I/O on your behalf. What you call a file descriptor is a pointer to an application level structure containing state information used by the standard I/O library. (And *only* by the standard I/O library). Among other things, this structure contains the file handle for the file. Note that the terminology your documentation uses is *not* universal. [I have only seen this terminology in the Lattice C compiler docs for MS-DOS, though MSC may also use it]. Be aware that in most UNIX docs the term file descriptor usually refers to what you call a file handle, and your 'file descriptor' is usually called a 'FILE pointer'. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
session@uncw.UUCP (Zack C. Sessions) (02/27/91)
cwong@charlie.coyote.trw.com (Chun Wong) writes: >Can someone distinguish the differences between a file descriptor and >a file handle? I know that creat returns a file handle whereas fopen >returns a file descriptor. What's the difference? Are they interchangeable? >-C. Wong A file handle as you call it is also referred to as a path. It is typically an int variable and is used by creat and open and read and write and close. (plus others). A File Descriptor is a special structure which is specific for your system and defined in your stdio.h defs file. It usually contains a file handle (path) as part of it's data structure. Files which you access with File Descriptors use the fopen, printf and scanf constructs, fread, fwrite, and fclose (plus others). The distinct difference between the two is that files accessed through a File Descriptor are accessed in a method call "buffered IO". This can sometimes greatly increase the performance of your program at runtime. Also, the "raw IO" calls are not always implemented the same on all machines or compilers and sometimes not implemented at all. Use of only buffered IO can usually guarantee portability if that's an issue. Zack Sessions ...!ecsvax!uncw!session
gwyn@smoke.brl.mil (Doug Gwyn) (02/27/91)
In article <27C9CB35.5F7@wilbur.coyote.trw.com> cwong@charlie.coyote.trw.com (Chun Wong) writes: >I know that creat returns a file handle whereas fopen >returns a file descriptor. What's the difference? Are they interchangeable? How can you "know" something that is false? On UNIX, which is the prototypical C environment, there is a set of system calls open(), creat(), read(), write(), close(), ioctl(), dup(), etc. that operate using I/O access information maintained within the operating system kernel, in tables that are indexed by small integers called "file descriptors". Such system calls do not necessarily exist for other operating system environments, so various "portable I/O library" interfaces were devised, leading to the "standard I/O library" described in K&R which served as the basis for the C standard's hosted- implementation required I/O support. The standard I/O package may or may not make use of file descriptors internally, but it provides for use by application programs pointers to FILE structures, sometimes called "stream pointers". A FILE structure contains implementation- specific information needed for the standard I/O functions to do their job properly. By the way, standard I/O also supports buffering of I/O data into fairly large blocks, which are read/written a blockful at a time. This allows use of functions such as getc() and putc() without the horribly expensive overhead that would arise if operating system I/O requests were performed for each byte individually.
peter@ficc.ferranti.com (Peter da Silva) (02/27/91)
Playing fast and loose with definitions... File descriptor: a small integer (0..n) indicating a file. File handle: O/S specific object referring to a file. May be a pointer, a file descriptor, or something more exotic. Equivalent in function to a UNIX file descriptor. File handle: in NFS, a file token. File pointer: a pointer to a structure created by stdio. Contains the file descriptor or file handle. File token: O/S specific object referring to a file, but may not actually be used to access a file (for example, in RMX-86 you DQ$ATTACH to a file to get a file token. To do I/O on it you DQ$OPEN the returned token. File lock: in AmigaDOS, a file token. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (02/28/91)
In article <1991Feb26.101038.1@dev8n.mdcbbs.com> campbell@dev8n.mdcbbs.com (Tim Campbell) writes: > Applies specificly to DOS (MS-DOS, IBM-DOS, etc.) based applications. > File Descripters were a carry over from CP/M - when a program needed to > open a file... Yo, I thought my table was complete. These beasties are "file control blocks" or FCBs. I've never seen them described as "file descriptors". But that doesn't mean IBM might not have done so. I would put nothing beyond IBM when it comes to screwing up terminology about files... data sets.... -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
reg@pinet.aip.org (Dr. Richard Glass) (02/28/91)
In article <27C9CB35.5F7@wilbur.coyote.trw.com> cwong@charlie.coyote.trw.com (Chun Wong) writes: >Can someone distinguish the differences between a file descriptor and >a file handle? I know that creat returns a file handle whereas fopen >returns a file descriptor. What's the difference? Are they interchangeable? > >-C. Wong I think what you want to know is what the difference between the IO routines read, write, creat versus fgets, fopen etc. The first set of routines are also known as Level I IO and "raw data movers". They perform NO translation of data andd read/write at the byte level. For example, doing a write(fd, &(x=0), sizeof(int) ) where x is an int will write "sizeof int" NUL ASCII characters. An fputc( x = 0,stream) will write the ASCII code for the character 0. The f - routines are the level 2 IO. They are the C language IO functions. Since C migrated from the UNIX enviornment, some of the UNIX kernal routines "became" part of the library in particular the level I IO routines of UNIX. I have yet to see a C compiler without the level 1 IO routines. But some of these compilers take liberty with the routines. Are they interchangable? They are as interchangable as int and char *. One is a pointer (level 2) and the other an int (not neccessarly small/short as someone suggested). Some libraries provide a fileno() macros that take a level 2 IO file descriptor and convert it to the level 1 IO handle. For system use, the most efficient way to read is to read(fd, buf, BUFSIZ) where buf is a char array of BUFSIZ and BUFSIZ is defined in stdio.h. There are UNIX calls (and sometimes C library) routines to adjust the buffering done by the process. NOTE: There in NO NULL byte placed on the end of the array 'buf'. To insure portability, level 2 should be used. One can perform untranslated IO using the routines fread and fwrite To read a file of structures 'struct s inst' (teminology stolen from Pascal land) the routines read(fd, (char *)&inst, sizeof( struct s)) should be equivalent to fread( &inst, sizeof( struct s ), 1, stream). Dr. Richard (Ricky) Glass
mike (02/28/91)
Egads! Such a difference in opinion over such a simple little thing.
Tis truly amazing. Anyhow, from the traditional school of thought:
1. When one refers to "handles" and "descriptors" in the classic
sense, you are talking about the *same* thing: a non-negative
integer that is an index into a table of open files local to
the process (children may inherit descriptors from their
parent upon their creation; its up to the parent process to
decide this.) Various implementations of an operating system
may change this. Not all operating systems grok this.
This is system dependant, and could be a Bad Thing if you are
worried about portability to "strange" operating systems.
2. The pointer that is returned by fopen() is a file _stream_
pointer. Not handle. Not descriptor. Not R4 STREAM either.
Stream. The whole point there was to isolate the programmer
from some of the dependancies of the underlying OS.
As a point of honour:
The concept of the file descriptor did NOT originate with that
black sheep known as DOS, nor that vile program loader known as
CP/M. It probably predates UNIX (circa 1969).
--
Michael Stefanik, MGI Inc., Los Angeles| Opinions stated are not even my own.
Title of the week: Systems Engineer | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
Remember folks: If you can't flame MS-DOS, then what _can_ you flame?ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (02/28/91)
In article <1021@uncw.UUCP>, session@uncw.UUCP (Zack C. Sessions) writes: > cwong@charlie.coyote.trw.com (Chun Wong) writes: > > >Can someone distinguish the differences between a file descriptor and > >a file handle? I know that creat returns a file handle whereas fopen > >returns a file descriptor. What's the difference? Are they interchangeable? > > >-C. Wong > > A file handle as you call it is also referred to as a path. It is > typically an int variable and is used by creat and open and read > and write and close. (plus others). A File Descriptor is a special > structure which is specific for your system and defined in your > stdio.h defs file. Hoo *boy*! From the System V Interface Definition (for real up-to-date definitions see IEEE 1003.1 and the ANSI C standard) file-descriptor A file-descriptor is a small integer used to identify a file for the purposes of doing I/O. The value of a file-descriptor is from 0 to {OPEN_MAX}-1. An open file-descriptor is obtained from a call to the creat(), dup(), fcntl(), open(), or pipe() routine. path-name In a C program, a path-name is a null-terminated character string starting with an optional slash, followed by zero or more directory-names separated by slashes, optionally followed by a file-name. ... (In Common Lisp, MIT Scheme, ZYX Prolog, and some other systems, a "path name" is a structure having Host, Device, Directory, Name, Type, and Version fields, and the string version is called a name-string.) stdio-stream A file with associated stdio buffering is called a stream. A stream is [represented by] a pointer to a type FILE defined by the header <stdio.h>. So, char *A_Path_Name = "/usr/include/stdio.h"; int A_File_Descriptor = open(A_Path_Name, O_RDONLY): FILE *A_Stdio_Stream = fdopen(A_File_Descriptor, "r"); In short, RTFM. -- The purpose of advertising is to destroy the freedom of the market.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (02/28/91)
In article <4842@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > > cwong@charlie.coyote.trw.com (Chun Wong) writes: > > >Can someone distinguish the differences between a file descriptor and > > >a file handle? I know that creat returns a file handle whereas fopen > > >returns a file descriptor. What's the difference? Are they interchangeable? I explained file-descriptor, path-name, and stdio-stream. I forgot to say anything about "handle". OS/2 documentation uses the word "handle" to mean exactly the same thing as UNIX means by "file descriptor". For example, the thing DosOpen() returns via its second argument is a "handle", which is a 16-bit integer, just as open() in UNIX returns an integer. In fact, just as standard input, output, and error have file descriptors 0, 1, and 2 in UNIX, so STDIN, STDOUT, and STDERR are 0, 1, and 2 in OS/2. "Handle" is used in other environments to mean a pointer to a pointer. You Have Been Warned. -- The purpose of advertising is to destroy the freedom of the market.
wirzenius@cc.helsinki.fi (Lars Wirzenius) (03/01/91)
In article <1991Feb27.192725.26421@pinet.aip.org>, reg@pinet.aip.org (Dr. Richard Glass) writes: > I think what you want to know is what the difference between the IO > routines read, write, creat versus fgets, fopen etc. The first set of > routines are also known as Level I IO and "raw data movers". They > perform NO translation of data andd read/write at the byte level. >[...] > To insure portability, level 2 should be used. One can perform > untranslated IO using the routines fread and fwrite The difference between 'level 1' (open, read, write, close) and 'level 2' (fopen, fgets, fputs, fclose, etc) is not that 'level 1' doesn't do translation and 'level 2' does, but that 'level 2' gives buffering and makes it easier to operate on 'meaningful' chunks of data, e.g. chars and lines. Remember, in Unix there is no translation needed, unlike most other systems. For portability and conformance to the standard, 'level 2' should be used. For efficiency, it depends. -- Lars Wirzenius wirzenius@cc.helsinki.fi
richter@immd4.informatik.uni-erlangen.de (Joachim Richter) (03/04/91)
In article <1021@uncw.UUCP> session@uncw.UUCP (Zack C. Sessions) writes: [13 lines deleted] >of it's data structure. Files which you access with File Descriptors >use the fopen, printf and scanf constructs, fread, fwrite, and >fclose (plus others). The distinct difference between the two is Is it really true, that you don't know that fopen returns a FILE * ? -------------------------- My real X.400 Address is ingo@cnve.rz.uni-jena.dbp.de Please don't use the address in the header. That's because this is a borrowed account ... Ingo ----- The german revolution from autumn 1989 will change europe's face -----
session@uncw.UUCP (Zack C. Sessions) (03/06/91)
richter@immd4.informatik.uni-erlangen.de (Joachim Richter) writes: >In article <1021@uncw.UUCP> session@uncw.UUCP (Zack C. Sessions) writes: >[13 lines deleted] >>of it's data structure. Files which you access with File Descriptors >>use the fopen, printf and scanf constructs, fread, fwrite, and >>fclose (plus others). The distinct difference between the two is >Is it really true, that you don't know that fopen returns a FILE * ? No, not true. I was using not exactly correct terminology, but I was trying to get the point across to a question which really wasn't "asked right" anyway. What I was referring to as a File Descriptor is what my C manual calls a "pointer to a file structure (file pointer)". The "other" was IO is performed with my C compiler is in "raw" mode designed to work with direct system calls. It uses an int variable to store what it calls the "path number". Zack Sessions session@uncw.UUCP