Re: [boost] Mac OS deprecating paths

From: Darin Adler (darin_at_[hidden])
Date: 2002-01-28 10:31:12

On 1/28/02 7:04 AM, "Jesse Jones" <jesjones_at_[hidden]> wrote:

>>> Aren't paths an implementation detail? What about OS's now and in the
>>> future that deprecate paths? I don't see why we can't create a higher
>>> level class that works just as well as a path-centric class, but also
>>> works well on the Mac OS.

Jesse, I think you are overstating the case a bit when you say that paths
are deprecated on Mac OS and always will be.

There is only one real problem with paths on the Mac OS. For pre-OS-X
versions of the Mac OS, there can be more than one volume with the same
name, so a path doesn't uniquely identify a file.

That's the reason paths were deprecated in pre-OS-X versions of the Mac OS.

Under Mac OS X, paths are not deprecated. Each volume is given a unique name
in the Unix file system while it's mounted, although the
duplicate-volume-name issue still exists within the Carbon file system
interface. There are many OS X native programs that simply use paths and
don't bother with the Carbon FSRef structure at all.

There's a lot more we could say about Macintosh paths and file naming, but
lets not make this more mysterious than it is.

That having been said, if we want a class that supports the pre-OS-X Mac OS
well, then we can't exactly use a "path" class. For this platform, the
volume part of the path must be a vRefNum, not a volume name. And as a side
note, URLs do no better. There's no URL syntax that works on these pre-OS-X
Mac OS systems to uniquely identify a file.

Of course the other things Jesse said are correct; on Mac OS one of the most
important operations on a path is conversion to and from one of the forms
used by the Carbon file system interface, particularly FSRef, but also
perhaps FSSpec and CFURLRef.

    -- Darin