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

Finder Selection proxy object refers to the original file when symbolic link is selected #1729

Closed
D-elias opened this issue Dec 19, 2013 · 9 comments
Labels
Milestone

Comments

@D-elias
Copy link

D-elias commented Dec 19, 2013

I have created a trigger to "delete the current selection". I use this all of the time as it saves time when deleting files. I deleted several symbolic links this way and the original files were deleted and the symbolic links were left.

@skurfer
Copy link
Member

skurfer commented Feb 7, 2014

I looked into this thinking there was some problem with the way we resolve the path, but it turns out the “Finder Selection” proxy contains the wrong path to begin with. That’s all done in AppleScript. I tried some things, but it seems bent on giving back the path to the actual file and not the symlink.

Maybe someone with AppleScript chops like @philostein has some ideas?

@philostein
Copy link
Contributor

philostein commented Feb 14, 2014

In AppleScript, the class of an alias or symlink is alias file. However, running this script:

tell application "Finder"
    file type of alias (selection as text)  
end tell

– with one file selected in Finder returns "slnk" for a symlink and "alis" for an alias, and missing value for a regular file, so AppleScript can tell the difference between symlinks, aliases and the originating files.

But even without checking for file type, this script:

tell application "Finder"
    delete selection
end tell

– only removes the symlink or alias, and leaves the source file untouched. So AppleScript shouldn't have to be the problem.

Playing around, I noticed that grabbing a symlink with ⌘⎋ places the source file in pane 1. Browsing to a symlink from its parent folder keeps the symlink in pane 1, which is deleted when using "Move to Trash" in pane 3. An AppleScript to act on a symlink grabbed into pane 1 would be of no use, as Quicksilver would be showing the source file instead.

@philostein
Copy link
Contributor

philostein commented Feb 14, 2014

I made an action using AppleScript:

using terms from application "Quicksilver"
    on open _file -- File in QS pane 1
        tell application "Finder"
            delete _file
        end tell
    end open
end using terms from

It deletes the source file even if a symlink is browsed to in pane 1.

@skurfer
Copy link
Member

skurfer commented Feb 15, 2014

I did some experimenting, but haven’t come up with a solution.

This is obviously wrong. With a symlink selected, it gives back the original file’s path.

tell application "Finder"
    get POSIX path of (selection as alias)
end tell

This is a little closer, but it only gives the file’s name and drops the rest of the path.

tell application "Finder"
    get POSIX path of (selection as POSIX file)
end tell

So, we could add the parent back with something like this…

tell application "Finder"
    set filename to POSIX path of (selection as POSIX file)
    set filepath to POSIX path of ((container of (selection as alias)) as alias)
    return filepath & filename
end tell

…but I assume that will break if the parent folder is a symlink.

@philostein
Copy link
Contributor

philostein commented Feb 16, 2014

So, we could add the parent back with something like this…

tell application "Finder" set filename to POSIX path of (selection as POSIX file) set filepath to POSIX path of ((container of (selection as alias)) as alias) return filepath & filename end tell.

…but I assume that will break if the parent folder is a symlink

If you put a file in a folder symlink, it goes into the source folder anyway, so does it matter?

Also, I get the wrong path when moving a symlink to a different folder:

screen region 2014-02-16 at 09 51 30

The script returns the original path the symlink was created in:
"/Users/phil/Test folders/Test folder 1/abc.txt symlink"

This script returns the current path of the symlink:

tell application "Finder"
    POSIX path of (selection as text)
end tell

Result:
"/Users/phil/Test folders/Test folder 1/Test folder 3/abc.txt symlink"

@philostein
Copy link
Contributor

philostein commented Feb 16, 2014

Another info nugget: browsing to a symlink and using "Move to Trash" in pane 2 deletes the symlink; browsing to a symlink and using "Move To…" in pane 2 moves the source file.

@skurfer
Copy link
Member

skurfer commented Feb 16, 2014

Holy crap. POSIX path of (selection as text) works exactly like my complicated work-around and is exactly what we’re looking for. Why didn’t you just say that to begin with? 😃

Ideally sym-linked folders would still appear in the path for consistency, but the file that ends up being targeted is correct, so I can live with it.

browsing to a symlink and using "Move To…" in pane 2 moves the source file.

I’ll need to look into that.

@lgarron
Copy link
Contributor

lgarron commented Jun 11, 2014

I'm not sure if this caused it, but I am no longer able to do the following:

  • Get Finder Selection in Quicksilver
  • ⌥→ to get the source symlink (just doesn't do anything)

I can find ways to get around this, but I'm not excited about spending time on git bisect to track down when this broke. Just thought I'd leave a note, in case this might affect others.

@skurfer
Copy link
Member

skurfer commented Jun 11, 2014

This was mentioned by someone else recently (and of course I can’t find it), but whether or not this is “broken” is debatable. To me, it feels like symlinks are first-class citizens now. In the other discussion, I suggested that a new action to resolve symbolic links (and aliases).

For what it’s worth, this didn’t cause the change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants