Noodlesoft Forums

Questions:

What happens when Move to Trash is clicked in the App Sweep window after Trash was emptied while it still contained the corresponding temporary Name.app Support Files folder? Also, is it okay to empty Trash containing the temp folder before clicking Keep All in the App Sweep window?

Suggestion:

Add an Open Trash button to the App Sweep window. That's for the sake of convenience when wanting to move a deleted app back to /Applications by dragging it to Finder's sidebar target (presuming it's visible in the Trash window) after the App Sweep window appears (and grabs focus). I know it wouldn't normally be used often but during my testing it's been awkward without it.

That suggestion ignores any consideration of possibly using the Finder/Trash Put Back feature since I'm not running Snow Leopard yet (and never will on my PPC systems).

Thanks.

Have you tried undo (command-z) to undo the throw away?

I haven't tested the case of emptying before "Move to Trash" but it may cause a problem. I'll file a bug for that. I'm guessing it should at least attempt to re-create the folder if it is missing.

"Keep All" does nothing, meaning, it won't throw away any additional files so it doesn't matter what you do to the trash then.

Mr_Noodle wrote:Have you tried undo (command-z) to undo the throw away?

I remember doing that awhile ago but stopped for some reason, maybe just forgetfulness. Thanks for the reminder to try it again.

I haven't tested the case of emptying before "Move to Trash" but it may cause a problem. I'll file a bug for that. I'm guessing it should at least attempt to re-create the folder if it is missing.

What about creating the temp folder only if "Move To Trash" is clicked? Seems like the easiest way to avoid Empty Trash removing it before it's possibly needed/used.

"Keep All" does nothing, meaning, it won't throw away any additional files so it doesn't matter what you do to the trash then.

Makes sense. Maybe I was wondering it could get confused by not finding the temp folder, which would be irrelevant anyway if only clicking "Move To Trash" created it.

The temp folder is created before the window comes up. The reason for this is architectural as there's a hand-off from one process to another and the one handing it off is the one that updates the internal record so the folder has to be created up front before the hand-off. That said, I'll look into having it compensate when after the hand-off the folder is no longer there.

I figured there was a good technical reason for doing it in the less obvious way.

The motivation for questioning this is to eventually be confident that using Empty Trash before the App Sweep window appears won't have any unwanted side effects instead of continuing to wonder if it will. If I'm able to Empty Trash with less attention on if/when the App Sweep window will appear that'll effectively resolve the interrupting delay issue. This probably wouldn't matter if I wasn't so compulsive about emptying Trash but that's one habit I don't see breaking any time soon.

Looking at it, it seems it works fine in this case. It will re-create the folder as needed.

Emptying the trash should be fine as long as you don't do it while Hazel is actually throwing away the files (like you hit "Move to Trash" and somehow also empty the trash at the same moment).

Mr_Noodle wrote:It will re-create the folder as needed

Presumably by the same process that created the original one; there's still no way to defer that original creation until it's needed.

like you hit "Move to Trash" and somehow also empty the trash at the same moment

That brief window of vulnerability is easily avoidable.

What I've had to be careful of during testing is not to mistakenly empty Trash before undoing app deletions. Infrequently used apps that can be easily drag/drop reinstalled if necessary are the best candidates to test with.