borcelf@jacobs.cs.orst.edu (Fernando Borcel) (09/21/89)
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 to?
Is it a reliable way to find a file?
Thanks a lot.
(*)(*)(*) Fernando Borcel (*)(*)(*)
borcelf@jacobs.cs.orst.edu
{tektronix,hp-pcd}!orstcs!jacobs.cs.orst.edu!borcelf
-----If a President doesn't do it to his wife, he'll do it to his country-----dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (09/21/89)
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. But...... System 7.0 is going to allow you to have unique file ID's that will be a way to find and open a file, even if it's been moved to another directory. So if your application isn't being released in the real near future you might want to look into holding off on the vRefNum and using the file-id instead. I WELCOME corrections or this, I am currently without my Mac documentation and I am going from memory. Hope this helps. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | God doesn't know, he would have never designed it like that in the first | |_ place. ____________________________________________________________________|
russotto@wam.UMD.EDU (09/21/89)
In article <12562@orstcs.CS.ORST.EDU> borcelf@jacobs.cs.orst.edu (Fernando Borcel) writes: >Is it [vrefnum] a reliable way to find a file? > >Thanks a lot. No. the vrefnum is dynamic, and are assigned starting at '-2' and in descending order. Use the volume name, directory ID, and file name as the most reliable way of finding a file across launches of your application. For the duration of an application, the vrefnum, dirID, and file name is safe (if the file is open, the refnum is enough). Having just the wdRefNum and file name is probably ok too, but I don't trust that. -- DISCLAIMER: Not only does the University not share my opinions, they don't want me sharing my opinions. "This 'Pnews', what does it do? Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu
rang@cs.wisc.edu (Anton Rang) (09/21/89)
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."
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (09/21/89)
rang@cs.wisc.edu (Anton Rang) writes: [politely corrects me after I put my foot in my mouth...] sorry for the incorrect information on the net. I was lead to believe by someother people that what I said was correct. In my defense inside mac doesn't seem to give a satisfactory answer to the original question. I always try and make my posting correct, but I've yet to hit 100%. My apologies to the net if anyone was confused by my posting. -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | God doesn't know, he would have never designed it like that in the first | |_ place. ____________________________________________________________________|
oster@dewey.soe.berkeley.edu (David Phillip Oster) (09/21/89)
This point is clearly covered in Inside Mac v. 4. the "vRef" of a folder is really a "wRef" a working directory reference. It only lives for a short time. You cannot depend on it from session to session. There is another number, a 4-byte dirId that is the permanent identifier of the folder, even if the folder is renamed. There is a system call that takes a wRef and a real volume reference and returns the dirId. PBHOpen() takes a volume Id, a dirId, and a file name and opens the file. To store a file descriptor from run to run, you need a triple: the volume name, the dirId, and the file name. To be really safe, you need the full path name too, so you can use it on a remote file system that doesn't really support dirIds. You need the volume name as a string since it may get a different number depending on the order of the mounting of the disks at boot time.