{"id":44325,"date":"2024-08-02T16:45:23","date_gmt":"2024-08-02T20:45:23","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44325"},"modified":"2024-11-25T15:14:16","modified_gmt":"2024-11-25T20:14:16","slug":"the-switch-from-file-paths-to-urls","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/08\/02\/the-switch-from-file-paths-to-urls\/","title":{"rendered":"The Switch From File Paths to URLs"},"content":{"rendered":"

Quinn<\/a>:<\/p>\n

I don’t think we ever documented this officially, but to understand this choice you have to look at the history of macOS. Traditional Mac OS did not use paths a lot. Rather, files were identified by an FSSpec<\/code>, which contains a volume identifier, a directory ID, and a name. The directory ID was an HFS [Plus] catalogue node ID (CNID), which is kinda like an inode number.<\/p>

Additionally, starting with System 7 it was possible to track a file with a volume identifier and the file ID, that is, the CNID of the file itself.<\/p>

This was quite tricky to support on a Unix-y platform like Mac OS X. At the lowest levels of the system you needed the ability to manipulate files based on CNIDs rather than paths. For an explanation of how this was done, see QA1113 The “\/.vol” directory and “volfs”<\/a> (note, however, that volfs<\/code> is no longer a thing and the same functionality is now implemented in a very different way).<\/p>

[…]<\/p>

So far, so much obscure backward compatibility. However, since we made the decision to use file URLs we’ve exploited that to significant advantage[…]<\/p><\/blockquote>\n\n

Via Matt Gallagher<\/a>:<\/p>\n

There’s a lesson about attaching data (like security attributes) to an opaque interface (like NSURL<\/code>). Because my mental model of NSURL<\/code> is as plain RFC-3986 storage, these attributes are easy to lose and the security behaviours are easy to forget, when moving data around an app (I wish we received a bookmark type that made this explicit).<\/p><\/blockquote>\n\n

Jim Luther<\/a>:<\/p>\n

\n

The original proposal was not to use a NS<\/code>\/CFString<\/code> object encapsulating the path or a NS<\/code>\/CFURL<\/code> object, and instead use a new object type to identify a file’s location, to cache properties, etc. That idea was vetoed in early API reviews because there were already API that took file locations as paths or URLs. We were told to pick path or URL. We chose URL objects over string objects.<\/p>\n

I still think a new object type would have been cleaner and better in the long run. 🤷‍♂️<\/p>\n

[…]<\/p>\n

FSRef<\/code>s were not objects so they didn’t fit into the Cocoa (or CoreFoundation)API memory model. They were also a fixed size glob of memory so expanding their functionality was very difficult. One of the things I did in my last year at Apple was to make the old Carbon File Manager work well with APFS and its 64-bit inode numbers. That meant making shoehorning 64-bit file and folder ids into FSRef<\/code>s and translating them to 32-bit ids for the old File Manager API. Fun hacking 😀<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n