wiechman@athos.rutgers.edu (NightMeower) (02/04/89)
Perhaps someone can help. What I'd like to do is using SFGetfile create a list of files to form a queue which could then be saved and read back in at a later time and processed. Admittedly, the user could trash/move some files. If at the time of processing the file wasn't available then it would be skipped. After tinkering with this for several days now, I have gotten no where. It would appear that just having the vrefnum and fname is not enough. So I have been including the dirid so that I can open a working directory. However, all or some of these numbers appear to be different when I try to process them at a later time. Ideas? At this point, I am starting to think that I will need to save a whole path name for each file. I would appreciate any ideas, comments, or code snipets that anyone may have that are related. Thanks in advance, Kevin -- =========================================================================== Kevin S. Wiechmann arpa: wiechman@rutgers.rutgers.edu This is only a test... for the next sixty seconds...
tim@hoptoad.uucp (Tim Maroney) (02/05/89)
In article <Feb.3.17.02.01.1989.2791@athos.rutgers.edu> wiechman@athos.rutgers.edu (NightMeower) writes: >Perhaps someone can help. What I'd like to do is using SFGetfile >create a list of files to form a queue which could then be saved and >read back in at a later time and processed. Admittedly, the user >could trash/move some files. If at the time of processing the file >wasn't available then it would be skipped. After tinkering with this >for several days now, I have gotten no where. It would appear that >just having the vrefnum and fname is not enough. So I have been >including the dirid so that I can open a working directory. However, >all or some of these numbers appear to be different when I try to >process them at a later time. Ideas? This is a bit vague. If you try to use the data again during the run of the application, there should be no problem. However, if you save this stuff to disk and then try to use it again after rebooting (or, I'd guess, relaunching) then it won't work -- the vRefNums from Standard File refer to working directories that have gone away. If you're trying to do this kind of lasting save, then you'll need, minimally, a volume name (not reference number, since after you reboot, the volume could be mounted in a different order or even on a floppy that hasn't been mounted), a directory id, and a file name. However, there are a few cases where saving a directory ID won't work, on hypothetical AFP servers, so it's better to save a full path name. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I've got troubles of my own, and you can't help me out. So take your meditations and your preparations and ram it up yer snout!" - Frank Zappa, "Kozmik Debris"
odawa@well.UUCP (Michael Odawa) (02/05/89)
In article <Feb.3.17.02.01.1989.2791@athos.rutgers.edu> wiechman@athos.rutgers.edu (NightMeower) writes: > >...What I'd like to do is using SFGetfile >create a list of files to form a queue which could then be saved and >read back in at a later time and processed....It would appear that >just having the vrefnum and fname is not enough. So I have been >including the dirid so that I can open a working directory. However, >all or some of these numbers appear to be different when I try to >process them at a later time. Ideas? >At this point, I am starting to think that I will need to save a whole >path name for each file. Don't save the whole path name. The file name and DirID are invariant, unless the user changes them intentionally. The vRefNum is dynamic; it's assigned when the working directory is opened. So, using SFGetFile, you would save the fName, convert the vRefNum to a DirID: with WDPB do begin ioNamePtr := nil; ioVRefNum := vRefNum; ioWDIndex := 0; ioWDProcID := 0; end; { with WDPB.. } if PBGetWDInfo(@WDPB, false) = noErr then DirID: := WDPB.ioWDDirID; But DirIDs are valid only within a particular volume, so you also need the volume name. You get this with: s := ''; with PB do begin ioNamePtr := @s iovRefNum := vRefNum; ioVolIndex := 0; end; { with PB.. } FSErr := PBHGetVInfo(@PB, false); if FSErr = noErr then VolName := s; Save the VolName and DirID with the fName. Then, when you want to work out your list, you have to: vRefNum := 0; SetVol(@VolName, 0); with WDPB do begin ioNamePtr := nil; ioVRefNum := 0; ioWDDirID := DirID; ioWDProcID := FinderSig; FSErr := PBOpenWD(@WDPB, false); if FSErr = noErr then vRefNum := ioVRefNum; end; { with WDPB.. } SetVol(nil, vRefNum); Now you should be back where you want to be; if the file fName isn't present, it's because the user has moved it. Notify him, and let him find it with SFGetFile. Oh, and why shouldn't we save whole path names? (a) Because they can be indefinitely long. (b) Because the above scheme will work even if the user changes the folders' names, or rearranges the nesting order of folders within his disk. Michael Odawa Simple Software odawa@well.UUCP
oster@dewey.soe.berkeley.edu (David Phillip Oster) (02/05/89)
In article <6449@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >do this kind of lasting save, then you'll need, minimally, a volume name >(not reference number, since after you reboot, the volume could be mounted >in a different order or even on a floppy that hasn't been mounted), a >directory id, and a file name. However, there are a few cases where saving >a directory ID won't work, on hypothetical AFP servers, so it's better >to save a full path name. This is right as far as it goes, but under the Macintosh file system, the dirId will still reference the same directory even if you rename the directory. In addition, the file system takes Pascal strings, which are limited to be at most 255 characters long, and path names are allowed to be longer than that. I store the pathname as a C string, and convert it at run time, in pieces if I have to. I also store the <volName, dirId, filename> triplet, and, in fact I try it first.