1) The API is poorly documented, and behaves differently on different macOS versions
2) Error reporting is really bad. Sometimes “opening” a bookmark fails, and there’s no indication why. The error message suggests that the user should change permissions in Finder, which is incorrect and misleading
3) It’s really easy to forget to “close” bookmarks, leading to leaked kernel resources (which might be one reason for 2)
4) Issues with code signing or the keychain can cause bookmarks to silently fail to open. There are no error messages that suggest this is the case, the only way to fix these problems is to search Google and try random things until it starts working again.
Bookmarks, just like the whole sandbox API, are a good idea in theory, but they suffer from poor documentation and extremely poor error reporting, making them unreliable. It’s no wonder developers are reluctant to adopt the sandbox unless they want to distribute their app on the App Store.
Maybe this area will get some attention with the rumored upcoming AppKit replacement.
Also, to be fair, I think that quality of the sandbox has improved significantly over the years. The remaining issues are in general pretty rare (my apps have thousands of users, and I only get a handful of support requests about these issues per year).
The problem is that when these issues pop up, there is nothing I can do to debug them -- aside from asking users "have you tried rebooting your computer?" (which does fix the issues occasionally)
Apple really needs to make better error reporting. When opening a security scoped bookmark fails, the system should return a proper error message, or at least log the reason for the failure.
And they must absolutely fix their error messages. When the sandbox denies access to a file, AppKit shouldn't suggest changing permissions in the Finder -- that won't help a thing.
I haven’t filed radars about the other issues since I was never able to reproduce them (only received customer reports). I haven’t seen any reports since the release of 10.13, though.
I should probably file radars for the poor documentation and the misleading error message.
Most apps don’t consider the inode as a user-visible (or user-significant) part of file metadata and so will make no effort to preserve it...
Notice that as of Sierra, apps can't just let you type in a path to choose a save location, or a library file, or whatever else? Your workflow has to pass through the File Open dialog. That's because the File Open dialog returns a Bookmark—and as long as the app retains the Bookmark, it retains the capability to read from/write to that folder (which it doesn't have by default.)
I tried using the command line to see what's under /.vol and nothing appeared. Which confused me, because I found some old stuff on the web that said I should see "a number" there. So apparently macOS no longer displays a volume number there.
StackExchange shows the simple technique: https://superuser.com/questions/163941/what-is-the-vol-direc...
You just stat a file to learn both its volume and inode. You can then use that pair to access the file:
$ stat /etc/hosts
234881026 23347035 -rw-r--r-- 1 root wheel 0 1035 "Jul 15 10:11:35 2010" "May 30 20:55:10 2010" "May 30 20:55:11 2010" "May 30 20:47:32 2010" 4096 8 0 /etc/hosts
$ head -3 /.vol/234881026/23347035
# Host Database
Mac apps have been working this way since the 1990s no problem.
Windows now allows you to delete an open file, however, the way this works is a bit of a hack. If you try to create a new file with the same name, the operation will fail until the deleted file is closed.
As a counterpoint, there are many situations where duplicating content may be preferred. If I'm pasting something into a document, I want it to remain immutable there without the risk of an external change (by me) altering the document that I assume to remain static.
The versioned database takes care of grouping related edits and lets you point at a specific, immutable version. While bidirectional links let you efficiently find all usage sites so that you can make an informed decision as to whether they need updating.
> This is reflected in the structure of our Home folders. We tend to put still images in Pictures, video in Movies, mail in Mail, then in Documents we collate content from those folders by duplicating it into finished documents.
> So long as we remain wedded to directory paths as a means of referencing files and folders, much of our storage will contain duplicated content. Bookmarks are a central part of a more advanced approach to structuring and organising content which can at last move on from the primitive constraints of MS-DOS.
> I think that we will see more, not less, use of Bookmarks as enduring file references in future versions of macOS. They don’t spell the end of inodes, aliases, links, or directory paths, but they need to be made much more accessible to users and sysadmins.
On the contrary, I think all of these approaches (duplication, bookmarks, inodes, symlinks) are destined to fail. I believe the problem of file organization cannot be solved adequately in a system of hierarchical mutable folders/files.
With regards to duplication, I propose the use of hash references. For example, you can put a picture somewhere on your disk, and let it be retrievable by its SHA-256 hash. Then, when you create a document that includes the picture, simply point to it by hash value - this avoids the need to duplicate the full picture content into the document.
I was holding out hope that Apple would publish a tool for working with aliases, or at least a specification of aliases so a 3rd party could design a tool. I have a volume with hundreds of aliases that don't work anymore, because the files they pointed to have moved to a new volume. I wish I could batch edit their paths, using find and replace. Many Apple users have asked for an alias editing tool, as I found when I went searching for one, to no avail - not even a kludgy hack exists. I wonder what risk such a tool would pose. Why doesn't Apple document the structure of aliases? Is it just because they're messy, like photoshop psds, and they don't want anyone to see their inelegance? Or is it because it would open Macs to new kinds of mischief? Aliases are fantastically useful, until they break.
> This is an extraordinary shortcoming. Imagine losing track of a stack of books when you move them from one room to another!
This is is how real life works -- there is no bookmarks in real life! If you had a stack of books, and you move it into the attic, all you your memory ("Bradbury is located near the floor on the left") will not work anymore. If a document was on your table, and you put it in the drawer, and then spilled the ink on the table, then your document will remain unmarked.
When applied to files, directories have meaning, and magic tracking links, as described in this article, would be surprising. When you delete old pictures from Photos, do you want some Keynote presentation, which lives in a completely different folder, break? When you move the file from 'current_info/' to 'outdated_info_do_not_use/', do you want old bookmarks to be still valid?
I'm not fine with it. It's an extra function call, it's more overhead to find and open a file, and it's much slower than placing a pointer to an inode.
Either your comment makes no sense at all or I don't understand what you're saying.