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

[D-elias]

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]

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]

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]

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]

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]

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:

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]

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]

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]

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]

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.