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

Old apps get sent to trash? #827

Closed
mdhari opened this issue Jun 20, 2016 · 5 comments
Closed

Old apps get sent to trash? #827

mdhari opened this issue Jun 20, 2016 · 5 comments

Comments

@mdhari
Copy link

mdhari commented Jun 20, 2016

My users are noticing that every time they update the app, the previous version gets sent to the trash. Is this a recovery mechanism by design? The trash is growing daily everyday, which is not something I would want since it's going to eat their hard disks too easily. I just want to remove it completely.

@mdhari
Copy link
Author

mdhari commented Jun 20, 2016

Changed the line in SUPlainInstaller.m from:

if (![constrainedFileManager moveItemAtURLToTrash:oldTempURL error:&trashError]) {

to

if (![constrainedFileManager removeItemAtURL:oldTempURL error:&trashError]) {

Deletes the old app now instead of moving to trash. Thanks.

@mdhari mdhari closed this as completed Jun 20, 2016
@zorgiepoo
Copy link
Member

Yes, old apps are moved to the trash by design. However this design is actually questionable and I could see a few issues:

  • Makes the update process not very seamless if we leave an old installation visible in the trash. Or in your case the app uses up disk space for users that won't empty it. I don't think other software updaters (App Store, web browsers) do this, though correct me if I'm wrong.
  • Moving an item to the trash could be an involved operation, doing more work and taking more time than necessary, and could even sometimes fail.
  • Apple's new file system will be able to do atomic save safe directory/bundle replacements, but as far as I know, only if the old bundle is removed (this means you can't end up in a state where both the new app is not installed and the old app is missing). Although copies/clones in the new system can also be cheap, allowing to back up the old bundle before replacing it efficiently..

But the upside is the user can refer back to the old app if something went wrong with the updated one.

Could you please re-open this issue, and in the future not close a bug report if it still affects Sparkle? Thanks.

@mdhari
Copy link
Author

mdhari commented Jun 21, 2016

Sure bud.

@schriftgestalt
Copy link

I just updated my sparkle-branch and saw that change by accident.

I don’t see that problems with the new file system. A move operation should be instantaneous as it only need to change the directory entry?

I really need the fallback that users can get the previous version back from the trash if there is a problem with the new version (mostly for beta versions).

@kornelski
Copy link
Member

kornelski commented Feb 24, 2019

For beta versions that does seem like a useful safety net indeed.

However, from my maintainer's perspective that still a no. I'ved used Trash in ImageOptim app and had to add a bunch of workarounds and fallbacks for it, and I still get reports about files that fail to delete, network driveas without trash support, Dropbox getting confused by replacing trashed files too quickly, etc.

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

No branches or pull requests

4 participants