• 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: "Philip Q" <email@hidden>
  • Date: Sun, 15 Jul 2007 00:35:47 +1200

On 14/07/07, Alastair Houghton <email@hidden> wrote:
On 13 Jul 2007, at 15:34, Thomas Engelmeier wrote:

> Am 13.07.2007 um 14:06 schrieb Alastair Houghton:
>
>> 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 is at best an implemenation detail, as a FSRef is not a
> recounted CFTypeRef, and there is no way to store a 1024 byte path
> (or even a 512 byte name + 8 byte dirID) in a 80 byte entity.

As I've said already, I was wrong about this.  I must have been
looking at an FSSpec or something.  That said, FSRef still has path
length problems on filesystems that don't support HFS+-style file IDs.


Not quite. "If the file system does not support "volfs", Carbon File Manager uses other techniques to emulate catalogue node IDs on that file system. In general these techniques do not provide persistent CNIDs. For example, if you use the Finder to create an alias to a file on a UFS file system and then move the file to a different folder, the alias will not resolve."

From:
<http://developer.apple.com/qa/qa2001/qa1113.html>

Sure, /.vol is not a documented or supported way of accessing files.
I wasn't advocating people actually using it, and it doesn't work
anyway except on HFS (and maybe AFP?).  My point was just that FSRef
isn't some sort of magic thing that can't be done from BSD; it's
implemented on top of BSD, not alongside it.


To a degree, it is alongside it. It's only use for the BSD system is to get access to volfs, which is implemented as its own VFS plugin, free from path issues.

-Phil
_______________________________________________

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


  • Follow-Ups:
    • Re: What are the official limits of Cocoa when it comes to the length of path names?
      • From: Alastair Houghton <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>)
 >Re: What are the official limits of Cocoa when it comes to the length of path names? (From: Thomas Engelmeier <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: NSTask and 45, "Operation not supported" error
  • Next by Date: Re: ColorSync Utility
  • 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