dickie@schaefer.math.wisc.edu (Garth Dickie) (01/17/91)
In article <48197@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >Most of the time, we recommend that people not use working directory >reference numbers. There is room for only a limited number of entries >in the table that keeps track of the vRefNum/dirID pairs. If you fill >up the table, gnarly things happen. However, there are a couple of >cases where it's necessary to use working directories: > >o When you call SFGet/PutFile. Standard File creates working directory > refernece numbers and returns them to you. When that happens, we > recommend that you convert them into their corresponding > vRefNum/dirID, and refer to the file with those values. I have wondered about an (infrequent) problem that this gives rise to: If you open a file from an application using SFGetFile, a working directory is created refering to the directory the file is in. If you then close the file and try to remove the directory from the finder, no luck: it can't empty the trash, presumably because the directory is pointed to by the wd. (is this correct?) If you close the application, you can then delete the directory; presumably the wd is reclaimed at this time. This does happen: if I want to rearrange the structure of my source tree, for example, in the middle of an edit session. The first thing that comes to mind is that an application should closewd the wd returned by SF. however, this might break the next SF call. maybe there is some other workaround? -- ------------------------------------------------------------- Garth A. Dickie dickie@macduffe.math.wisc.edu