URLByResolvingAliasFileAtURL: Appears to Be Broken - resolves to the the wrong folder

Question

Created 3d

Replies 2

Boosts 0

Participants 2

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using:

NSURL +URLByResolvingAliasFileAtURL:

What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of.

So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder).

Couple details:

My app is not sandboxed.
I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it).

Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense.

I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

Boost

Answer 1

Macho Man Randy Savage OP

3d

Actually if I create the alias in my app using -bookmarkDataWithOptions:includingResourceValuesForKeys:relativeToURL:error: it resolves proper.

so it appears to be an issue with the way Finder makes aliases. Maybe they are using relativeToURL: parameter? Weird.

0

Answer 2

DTS Engineer OP

Apple

11h

So if I create an alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...

Please file a bug on this and then post the bug number back here. I can explain what's going on, but URLByResolvingAliasFileAtURL should always resolve to the same location as the Finder.

Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder.

So, making things concrete, the actual issue here is the following configuration sequence:

(1)
Create an alias file to the target "beside" that target:

target
target alias
NewDir
   target

(2)
Move the object into a new directory "beside" another object with the same name as the target:

target
NewDir
   target alias
   target

What's going on here is that bookmark resolution is driven by heuristics, one factor of which is the relative position of the bookmark and its target. Those heuristics are what allow resolution to succeed even when the original target object no longer exists— for example, when a directory is deleted and then recreated or when an alias and its target are moved to a different volume.

The problem here is that the Finder and URLByResolvingAliasFileAtURL aren't using identical heuristics (and they should be). You can see this for yourself if you start with the configuration above, starting with URLByResolvingAliasFileAtURL resolving to this:

.../NewDir/target

NOW, rename that object so you end up with this:

target
NewDir
   target_old
   target alias

And resolution now returns:

.../target

Note that this isn't actually about a simple name match either, as this configuration:

foobar
NewDir
   target_old
   target alias

Resolves to this:

.../foobar

But then changing to this:

foobar
NewDir
   target
   target alias

Goes back to this:

.../NewDir/target

In other words, the issue isn't that URLByResolvingAliasFileAtURL can't find the target, it's that it's preferring the "local" name match over the other resolution path.

So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder).

Is your code writing out new alias files for stale files (which would do exactly what you're describing)?

If not, can you post the EXACT steps you did to make this happen? I've replicated the general issue you've described, but I haven't been able to get the Finder to switch resolve targets.

So it appears to be an issue with the way Finder makes aliases.

I haven't looked at the code in depth but I wouldn't be surprised if the Finder was writing a slightly different format. The term "alias" actually comes from an original, classic macOS, data format. Bookmarks replaced that format in ~10.6, but I wouldn't be surprised if the Finder still had some level of support to provide backward compatibility.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0