Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #288 fix (symlinks) #351

Merged
merged 4 commits into from Jun 18, 2011
Merged

Issue #288 fix (symlinks) #351

merged 4 commits into from Jun 18, 2011

Conversation

hmac
Copy link

@hmac hmac commented Jun 5, 2011

Prevents QS from resolving symlinks too early, so the resulting QSObject refers to the symlink instead of the destination file of the symlink.

@skurfer
Copy link
Member

@skurfer skurfer commented Jun 5, 2011

Seems to work well. I never knew that right-arrowing into a symlink would take you to the original. Cool feature. (Although I have to think that was probably also broken prior to this pull request since the link and the original would have been indistinguishable in the catalog. Too lazy to verify.)

@hmac
Copy link
Author

@hmac hmac commented Jun 5, 2011

The only issue I noticed is that symlinks that are already in the catalog before this change will stay broken. I fixed this while working on it by forcing a call to -purgeIdentifiers, but I suppose rescanning the catalog does the same thing?

@skurfer
Copy link
Member

@skurfer skurfer commented Jun 6, 2011

The only issue I noticed is that symlinks that are already in the catalog before this change will stay broken.

Ah, that makes sense. I couldn’t think of any symlinks off the top of my head, so I created a new folder/file/link to test with, so I wouldn’t have run across this.

I fixed this while working on it by forcing a call to -purgeIdentifiers, but I suppose rescanning the catalog does the same thing?

If a user does it by hand maybe, but if the parent folder hasn’t been modified, Quicksilver probably won’t re-examine it and update the catalog. But that’s speculation. Maybe you should try to reproduce the problem, but don’t rescan manually then see if it’s fixed after an hour or so.

@hmac
Copy link
Author

@hmac hmac commented Jun 6, 2011

Well actually, having said that I can't seem to reproduce the problem. Maybe I was mistaken. Every 'old' (made, then browsed with master branch QS) link I make shows up completely fixed on this build of QS.

@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Jun 17, 2011

So, are there any unresolved issues with this? Or can this be merged?

@hmac
Copy link
Author

@hmac hmac commented Jun 17, 2011

I'm not aware of any problems with it. I thought there might be an issue with symlinks already in the catalog but I was unable to reproduce it, so I think it's all good.

@skurfer
Copy link
Member

@skurfer skurfer commented Jun 18, 2011

I’ve had it merged into my local copy since this request was opened and haven’t had any problems (though I don’t run across many symlinks). I’m comfortable with you merging it.

HenningJ added a commit that referenced this issue Jun 18, 2011
@HenningJ HenningJ merged commit 42e213f into quicksilver:master Jun 18, 2011
@HenningJ
Copy link
Contributor

@HenningJ HenningJ commented Jun 18, 2011

Great. Merged. :-)

@hmac hmac deleted the symlinks branch Aug 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants