Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!prls!pyramid!cbmvax!uunet!efi!tim From: tim@efi.com (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Full Path Names (Was: Launching application returned in an SFReply record.) Message-ID: <1990Aug29.201842.14442@efi.com> Date: 29 Aug 90 20:18:42 GMT References: <25810@cs.yale.edu> <2079@cod.NOSC.MIL> <1990Aug23.154101.12931@efi.com> <11209@claris.com> Organization: Electronics For Imaging, Inc. Lines: 28 In article <25810@cs.yale.edu> braun-eric@CS.YALE.EDU (Eric E. Braun) writes: >>>> ... Is there any function hidden in IM somplace that returns a full >>>>path name given an SFReply? In article <2079@cod.NOSC.MIL> sampson@cod.nosc.mil.UUCP (Charles H. Sampson) writes: >>> At least two respondents have given routines that generate the full path >>>name. I haven't analyzed them to see if they work (they probably do), but one >>>problem with this approach is that the generated path name could theoretically >>>be longer than 255 characters (the maximum size of Str255). I doubt that such >>>a case would ever arise in the real world. Does anyone know of a case where >>>where it did? tim@efi.com (Tim Maroney) writes: >>Well, no, but folders can nest to any depth. This could happen very >>quickly if someone is fond of giving folders names like "The Unbearable >>Lightness of Being". I wrote a C routine that at least won't crash in >>this case, and with a little work to parse long file names, could cope >>with it cleanly: In article <11209@claris.com> drc@claris.com (Dennis Cohen) writes: >While Tim's code and suggestion will work, the paragraph above is in error. >File (and folder) names are limited to 31 chars in length on an HFS volume. Which I'm well aware of. The paragraph is not in error, except that my humorous example is two characters over. If someone is fond of giving files and folders this kind of name, then a few depths of nesting could result in full path names longer than 256 characters.