Hi Cov, Since on Mon, 2 Apr 2001 18:26:20 +0100 you were worrying about these guys: WDRN% = a soft working directory ref num (short) DN% = a soft drive number (short) HDN& = a hard directory number (long) -- hard means durable across restarts -- soft means not durable it is time for me to clean up a "faux pas" I posted conjecturally in Feb under the title "file passing quandry [FB]" Tue, 27 Feb 2001 03:06:33 +0100 (MET). I wrote for FBII nomenclature: << The sibling application can then get back a WDRN% suitable to itself by feeding the received HDN& and DN% to FN GETVOLINFO. >> That is sometimes WRONG (it's unreliable). A satisfactory call (still FBII) seems to be CLEAR LOCAL DIM err%, pBlk.52 LOCAL FN GetWDRefNum%(HDN&,DN%,errPtr&) pBlk.ioNamePtr& = 0 pBlk.ioWDDirID& = HDN& pBlk.ioWDProcID& = _"ERIK" pBlk.ioVRefNum% = DN% errPtr&.0% = FN OPENWD(@pBlk) END FN = pBlk.ioVRefNum% Said in English, you feed to FN GetWDRefNum% the above HDN&,DN% plus a place @error% to store the error% returned by the file manager call FN OPENWD. Then WDRN% = FN GetWDRefNum%(HDN&,DN%,@error%) is a valid recipe for WDRN%, and error% will contain the the possible error% (zero means no error). (Concerning _"ERIK", see Rick Brown's comments in the digests.) For FB^3 with the Toolbox runtime, the key change required should be OPENWD ==> PBOPENWD Maybe someone has some tested FB^3 code to post. Cheers Larry S PS. If you expect working directory ref num's to disappear any time soon, you will want to avoid them as Heather has recently indicated.