resolve aliases when browsing in the 3rd pane (by type). Fixes #1484

[pjrobertson]

Does what it says on the tin.
I created a new method for file objects to easily get the resolved object of an alias object. It can be used 'blindly' to resolve objects (i.e. if the object isn't an alias then calling [anObj resolvedAliasObject] just returns anObj

I contemplated changing isDirectory and isFolder to look at the resolved object (since they fail for file objects that are aliases to folders), but thought that it would be better to let the developer make the decision as to whether they want to distinguish folders and aliases (if not then just call resolvedAliasObject on the object)

[skurfer]

I'm not seeing any difference in behavior here. Does it literally have to be an HFS+ alias? Because I'm testing with a symbolic link.

I contemplated changing isDirectory and isFolder to look at the resolved object…

I think you made the right choice here for the right reason.

[pjrobertson]

I'm using a soft link (created with ln -s) and I can confirm it fixes the
problem.

Just to clarify: this doesn't fix the problem for the initial objects in
the 3rd pane, only when you right arrow into a folder...

edit
OK, it does fix that now. See the latest commit. Also, I've changed a few
other places in the code to consider the resolved object as opposed to the
original as well.

On 30 April 2013 02:30, Rob McBroom notifications@github.com wrote:

I'm not seeing any difference in behavior here. Does it literally have to
be an HFS+ alias? Because I'm testing with a symbolic link.

I contemplated changing isDirectory and isFolder to look at the resolved
object

I think you made the right choice here for the right reason.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1485#issuecomment-17188638
.

[skurfer]

I had created a folder and a symlink to it in my home directory, so I was going to ~ then hitting /. I'll get the new commits and test some more.

[pjrobertson]

@skurfer any updates on this pull? It should be good to go It got so old, that I actually completely forgot about it, and saw #1484 still open, so started re-fixing it... until I thought I could have sworn I'd already fixed it!

30 minutes of my time re-fixing the bug. Oh well! :P

[skurfer]

Already merged, but FYI, I can get to symlinks if I search for them directly in the third pane, but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

[pjrobertson]

Great, thanks Rob

but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

Really, works fine for me?
I have a symlink for /Uni which points to the real folder at /Documents/Uni
If I find '' in the 3rd pane, then hit → the '/Documents/Uni' folder shows up.

On 11 Meh 2013, at 04:05, Rob McBroom notifications@github.com wrote:

but if I search for the parent folder of a symlink, then navigate to its children, the symlink doesn't appear.

[skurfer]

OK, I see what's going on. I had something like this:

~/link → ~/folder

I just tried creating

~/Uni → ~/Documents/School

and the symlink appears now when I navigate into my home directory, but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

When I had a link to a folder in the same directory, the "resolved" path would have been a duplicate of the real thing, which was already included, which is why I never saw it.

[pjrobertson]

but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

I got started on fixing this the other day, then looked at how Finder does this… (turn on "View" > "Show Path Bar")
If you go to column view, you'll see that whilst it looks like you're in

username > Uni

the path bar actually shows:

username > Documents > School

So I decided that we should be consistent with what Finder shows, although it is still confusing (you hit ← and you end up in '' not '/Documents' as you might think

On 12 Meh 2013, at 01:24, Rob McBroom notifications@github.com wrote:

OK, I see what's going on. I had something like this:

~/link → ~/folder
I just tried creating

~/Uni → ~/Documents/School
and the symlink appears now when I navigate into my home directory, but it appears with the name and location of the real folder. Better than nothing, but probably not what people expect. I think there's already an issue open for that.

When I had a link to a folder in the same directory, the "resolved" path would have been a duplicate of the real thing, which was already included, which is why I never saw it.

—
Reply to this email directly or view it on GitHub.