Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uwm.edu!uwvax!rang From: rang@cs.wisc.edu (Anton Rang) Newsgroups: comp.sys.mac.programmer Subject: Re: HFS Help Message-ID: Date: 21 Sep 89 04:03:03 GMT References: <12562@orstcs.CS.ORST.EDU> <1989Sep21.014654.27408@polyslo.CalPoly.EDU> Sender: news@spool.cs.wisc.edu Organization: UW-Madison CS department Lines: 32 In-reply-to: dorourke@polyslo.CalPoly.EDU's message of 21 Sep 89 01:46:54 GMT In article <1989Sep21.014654.27408@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: >borcelf@jacobs.cs.orst.edu (Fernando Borcel) writes: >>I have a question that IM doesn't seem to answer too clearly... A vRefNum is >>a number assigned to the volume during runtime, or is it a number I can trust >>so when the next time I want to open a file in volume vRefNum I will be able > > Off the top of my head {ie. I could be wrong} I believe vRefNum's are good >for the life of the folder {or volume}, I would have to say that yes it >is. A vRefNum is good: (a) After a volume has been mounted, and (b) until the volume is dismounted. So it will be valid during a single run of a program, provided that the volume is not dismounted (note that under MultiFinder, the user may dismount (by ejecting) a floppy if no files are currently open on it. It is not reliable over multiple runs of the program, or if the user dismounts it from under you (which will not happen if you have a file open on it). In other words, it isn't a unique ID for a particular disk. Anton +----------------------------------+------------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | | University of Wisconsin--Madison | | +----------------------------------+------------------+ "You are in a twisty little maze of Unix versions, all different."