Re: curious: if not file references, what?
Re: curious: if not file references, what?
- Subject: Re: curious: if not file references, what?
- From: Quincey Morris <email@hidden>
- Date: Fri, 20 Jan 2017 20:24:29 -0800
- Feedback-id: 167118m:167118agrif8a:167118sVoU5uXDoP:SMTPCORP
On Jan 20, 2017, at 19:10 , David Young <email@hidden> wrote:
>
> This discussion seems to connect with a question I have had: what's the
> "proper" way to refer from a first document to a second document, if
> the second document may not have a fixed location in the filesystem?
> It sounds like "file references" (perhaps these are roughly in
> correspondence with an inode number?) are on their way out.
It’s not precisely the answer to the question of file references, but the correct way to reference one document from another is to use security scoped bookmarks. That throws the task of tracking the referenced file onto the system (a bookmark is much the same thing as an alias), plus it incorporates the sandbox-puncturing security check that allows you to re-open the referenced file when your app is re-launched, assuming the file was chosen by a user originally.
Currently, a bookmark might incorporate a file-reference URL and/or a file-path URL along with other metadata. If file-reference URLs are deprecated, the bookmark can be assumed to continue working regardless, and there should be no evil consequences from your point of view.
That’s assuming your app is sandboxed. If not, then just a regular bookmark should be fine.
It seems to me that the file-reference *behavior* is unlikely to go away. If anything changes, perhaps it will be that a file reference is no longer a kind of URL, but some other new class. Think about FileSpecs and FileRefs, which had API support for many years (at least 10, IIRC) after they were no longer recommended for use.
It’s an interesting question whether file-references use inode numbers. Some file systems don’t have them, so (I assume) they’re invented when such a file system is mounted, but they’re not necessarily assigned permanently across mounts. (I believe Apple documentation says not rely on the file number returned by NSURL metadata methods being stable across mounts.) Even when they’re baked into the file system, it’s not obvious what the semantics are when a volume is copied, or a volume is restored from backup. Perhaps someone else on this list is better informed on the subject than I am.
_______________________________________________
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