• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: What are the official limits of Cocoa when it comes to the length of path names?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What are the official limits of Cocoa when it comes to the length of path names?


  • Subject: Re: What are the official limits of Cocoa when it comes to the length of path names?
  • From: Steve Christensen <email@hidden>
  • Date: Fri, 13 Jul 2007 07:18:06 -0700

On Jul 13, 2007, at 5:06 AM, Alastair Houghton wrote:

On 13 Jul 2007, at 11:36, Stéphane Sudre wrote:

The limitation is in the Cocoa framework.

Well it may actually be in the kernel. If it's in the framework then it should be fixed, since there's no reason for the framework to limit the length of a path.

I think it's more likely that the limitation is in the OS itself since you run into path length issues in Carbon-land as well.


Actually, I'm tracking an issue with Alias resolution and I'm testing different cases to see where the problem might come from. My biggest surprise so far is that the same limit affects CFURLGetFSRef.

This isn't especially surprising, because (if I remember rightly) FSRefs internally store a path (on Mac OS X, anyway; earlier versions presumably hold a CNID instead).

That would be hard to do since FSRefs are 80 byte structures. I think it's more likely that they contain file IDs or something like that.


It's easy to get the impression that FSRef is a workaround for this problem, particularly because FSRefs constructed using legacy Carbon APIs may point to something in the fake /.vol folder (on HFS + anyway), which I believe is used to provide direct access to files by CNID (and which can, on HFS+, be used to access files whose pathnames are too long). This trick won't work at all on other filesystems, I shouldn't think.

It's a workaround -if- the OS has FSRef support for a particular file system and you can convert the path to a FSRef in the first place. I don't know offhand which file systems (beyond HFS+) might be supported, nor do I know if path to FSRef conversion (e.g., FSPathMakeRef, CFURLGetFSRef) will fail with path lengths larger than PATH_MAX.


steve

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >What are the official limits of Cocoa when it comes to the length of path names? (From: Stéphane Sudre <email@hidden>)
 >Re: What are the official limits of Cocoa when it comes to the length of path names? (From: "Stefan Werner" <email@hidden>)
 >Re: What are the official limits of Cocoa when it comes to the length of path names? (From: Stéphane Sudre <email@hidden>)
 >Re: What are the official limits of Cocoa when it comes to the length of path names? (From: Alastair Houghton <email@hidden>)

  • Prev by Date: Re: What are the official limits of Cocoa when it comes to the length of path names?
  • Next by Date: Re: Using proxy objects with NSMutableArray
  • Previous by thread: Re: What are the official limits of Cocoa when it comes to the length of path names?
  • Next by thread: Re: What are the official limits of Cocoa when it comes to the length of path names?
  • Index(es):
    • Date
    • Thread