Move to Trash action doesn't enable Put Back

[1.61803]

Deleting using ⌘⌫ works fine.

QS 1.2.0, OS X 10.8.5

[Rob McBroom]

True. Much ink has been spilled talking about that (by other devs), but
I don’t know what the exact issue is.

--
Rob McBroom
http://www.skurfer.com/

[1.61803]

On Monday, May 18, 2015 at 1:26:44 PM UTC+2, Rob McBroom wrote:

True. Much ink has been spilled talking about that (by other devs), but
I don’t know what the exact issue is.

I just ran a quick test with AppleScript

tell application "Finder" to move selection to trash

and bash

$ touch test

$ mv test ~/.Trash/

and both enable Put Back. Even 'QS selection → Move To… → Trash' works fine.

Do you want me to open an issue in the tracker?

[Etienne Samson]

The Finder does its special sauce when you use the shortcut, and NSWorkspace (which we use to perform the "Move to trash" step) doesn't. AFAIK there's no public way of making that work, short of reimplementing the whole "Move to trash" thing, reverse-engineering what/where/how Finder stores its Put Back info, and just making it Work Right™ w.r.t to duplicates, external volumes and other nice, fiddly things.

The best is to file a radar.

Note that here, neither the AppleScript method, nor the bash method you've pointed out since work. Make sure that you're trying with something you've not already "Move to trash"ed because it seems it's easy to make Finder lose track of which file came from where, so "Put back" doesn't actually Put back the *real*original file (I've just been bitten by that while doing a quick NSWorkspace check).

Test code, which doesn't enable Put back, in case you're curious...

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
NSError *error = nil;
NSURL *fileURL = [[NSURL fileURLWithPath:@"~/testfile"] URLByStandardizingPath];

NSAssert(fileURL != nil, @"fileURL is nil");

if (![[NSFileManager defaultManager] createDirectoryAtURL:[fileURL URLByDeletingLastPathComponent] withIntermediateDirectories:YES attributes:nil error:&error]) {
[NSApp presentError:error];
[NSApp terminate:self];
}

if (![@"testFile" writeToURL:fileURL atomically:YES encoding:NSUTF8StringEncoding error:&error]) {
[NSApp presentError:error];
[NSApp terminate:self];
}

[[NSWorkspace sharedWorkspace] recycleURLs:@[fileURL] completionHandler:^(NSDictionary *newURLs, NSError *error) {
NSLog(@"%@ => %@", newURLs, error);
}];
}

Cordialement,
Etienne Samson
--
samson....@gmail.com

> --
> You received this message because you are subscribed to the Google Groups "Quicksilver" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to blacktree-quicks...@googlegroups.com.
> To post to this group, send email to blacktree-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/blacktree-quicksilver.
> For more options, visit https://groups.google.com/d/optout.

[Jon Stovell]

On Monday, May 18, 2015 at 6:39:18 AM UTC-6, Etienne wrote:

Note that here, neither the AppleScript method, nor the bash method you've pointed out since work.

That’s not quite correct, at least on OS X 10.10. Try the following in Script Editor for evidence.

set thefile to (POSIX file (do shell script "mktemp ~/Desktop/foo.XXXXX")) as alias
delay 1 -- So we can see it on the desktop before moving on
tell application "Finder"
 delete thefile
 reveal thefile -- Shows it in the Trash
end tell
-- Now right click on the file in the Trash. The Put Back option will be available, at least on OS X Yosemite.

Perhaps a simple solution would be to reimplement the Move to Trash action as an AppleScript call to Finder?

[Etienne Samson]

Okay, so now the AppleScript works here too :-S.

I'm not *too* fond of using AppleScript for that reason — I can remember the "kill appleeventsd" days. I can also hear the PathFinder users yelling at us that QS activates the Finder when moving things to the Trash ;-).

What we could do is actually reselect the collection of objects that was trashed instead of IMHO the useless "parent folder" we return now. And then maybe doing some wiggly-dancing and store the old file's path in the object so that at least QS can "Put Back" — not that I will work on that though :-S. As I said, there's no way to get a grab of that "trashed file <-> original file" equivalence anywhere — I've looked at some obvious places (extended attributes came to mind), as well as Finder's behavior under fseventer, and even after a Force-Quit cycle it remembers where to Put Back so it's definitely storing something somewhere.

I'd say file an issue, though I think it's duplicated already ;-).

Regards,
Etienne Samson
--
samson....@gmail.com

[Jon Stovell]

On Thursday, May 21, 2015 at 2:36:15 PM UTC-6, Etienne wrote:

I'm not *too* fond of using AppleScript for that reason — I can remember the "kill appleeventsd" days. I can also hear the PathFinder users yelling at us that QS activates the Finder when moving things to the Trash ;-).

What about doing something like this pseudocode? 

if Finder is running
    use AppleScript to tell Finder to move the file to the trash
else
   do what QS does now
end if

[1.61803]

On Thursday, May 21, 2015 at 10:36:15 PM UTC+2, Etienne wrote:

As I said, there's no way to get a grab of that "trashed file <-> original file" equivalence anywhere — I've looked at some obvious places (extended attributes came to mind), as well as Finder's behavior under fseventer, and even after a Force-Quit cycle it remembers where to Put Back so it's definitely storing something somewhere.

Check this post at SU. Both tools in the answers don't work for me (the applescript calls a program I don't have the source for, the perl script needs probably an update of @INC on my part) but at least gives us a hint. Keep in mind that even after moving a file to the trash, and deleting the dsstore, it remembers the path. Somewhere I read that it stores it in memory and regularly updates the dsstore. When I checked it with fseventer a while ago I recall some encrypted mds db that might be involved too.

[David Shepherdson]

On Friday, 22 May 2015 06:36:15 UTC+10, Etienne wrote:

I can also hear the PathFinder users yelling at us that QS activates the Finder when moving things to the Trash ;-).

For what it's worth, Path Finder seems to have its own working 'Put Back' functionality -- as in, I move something to the Trash in PathFinder, and I then get a Put Back option in the contextual menu when I go to the Trash. This doesn't appear to be compatible with the Finder’s, though, because if I look at the same file in the Trash in the Finder, there’s no Put Back option.

Unfortunately it doesn't seem to work through the AppleScript interface; taking the script above and modifying it to target Path Finder instead of Finder, the file in the Trash doesn't have the Put Back option. There don't seem to be any extended attributes or resource fork changes on the files moved to the Trash through the Path Finder UI, so it must be storing the original paths somewhere else -- probably in ~/Library/Application Support/Path Finder/Settings/Data Store/trashAttributes.plist, by the look of it.

David Shepherdson

[1.61803]

On Thursday, May 21, 2015 at 10:36:15 PM UTC+2, Etienne wrote:

I'd say file an issue, though I think it's duplicated already ;-).

This applescript enabled only in QS as a trigger could be a workaround

-- QS app focus is tricky, script needs better error handling a/o QS notification

tell application "Quıcĸsıɩⅴεʀ"

    activate

    set theFiles to selection

end tell

tell application "Finder"

    try

        move theFiles to trash

    end try

end tell

But I couldn't set ⌘⌫ as a shortcut for QS only. Is it a bug?