Let the import be reviewed before it actually does something

[gimplyworxs]

Basically as the title.
This morning I tried the app trying to import data and was astonished that seemingly nothing really happens until finally I saw that everything was already imported.
I would find it nice if I could finally approve what is going to be imported.
So maybe have a list of what the app is planning to do, and a possibility to tick what I want and deselect what not.

[vikdevelop]

Hello,
thanks for your idea.
However, I think this feature is useless, because you can, before clicking on the Save button, click on the "Items to include in the configuration archive" and select the items you want, and then click on the mentioned button. So, it doesn't make any sense to select items before importing the configuration, because it will be imported only items that are located in the archive.

[gimplyworxs]

Linux Mint's Backup of the software list for example does it. It let's me review what's going to happen.
I can still uncheck apps that I don't want any more before it gets serious.
Well, it was just an idea.

[aroldobossoni]

Complaint about Save Desktop's destructive restore behavior

I want to report what I consider to be a serious usability and design flaw in Save Desktop's backup restoration process.

I imported a backup into my Fedora Bluefin KDE system expecting the application to give me an opportunity to review the contents of the backup and choose what I wanted to restore. Instead, the application immediately proceeded with the restoration process without giving me a meaningful confirmation step or a clear way to select which components should be restored.

This is an extremely dangerous design choice for a backup/restore application.

The backup I imported had been created on a completely different system: Pop!_OS using the COSMIC desktop environment. My current system is Fedora Bluefin with KDE Plasma. Obviously, I did not want to blindly restore desktop-environment-specific configuration from COSMIC into KDE.

The application even created an automatic startup mechanism to continue installing Flatpak applications after reboot. The message indicated that the Flatpaks would be reinstalled after restarting the system. This is particularly concerning because a user can reasonably interpret "Import backup" as importing or inspecting a backup, not immediately applying everything contained in it.

I had to investigate the application's files, scripts, temporary workspace, ZIP archive, Flatpak installer and autostart configuration manually just to understand what had happened and prevent the restoration from continuing.

I spent 3 hours undoing what this piece-of-crap app did because when importing a backup it immediately restores it.

That should never happen without a clear confirmation step.

A proper restoration workflow should be something like:

1. Select the backup.
2. Analyze and display its contents.
3. Show exactly what will be changed.
4. Allow the user to select what should be restored.
5. Clearly warn about potentially incompatible desktop environments or configurations.
6. Ask for explicit confirmation.
7. Only then perform the restoration.
8. Provide an easy rollback/undo mechanism.

Instead, Save Desktop effectively treated "import backup" as "restore backup immediately."

There should also be a clear distinction between:

• importing/opening a backup for inspection;
• selecting components from a backup;
• restoring configuration;
• restoring application data;
• reinstalling applications;
• restoring desktop-environment-specific settings.

Those are completely different operations and should not be silently combined.

The fact that the backup came from COSMIC while the destination system was KDE made this especially problematic. A restoration tool should be extremely conservative when it detects that the source and destination desktop environments differ.

I was fortunate enough to notice the Flatpak autostart behavior before rebooting. Otherwise, the application would have continued modifying my system automatically on the next login.

This is, without exaggeration, the worst app I have ever seen for this kind of task.

The concept behind Save Desktop is useful, but the restoration UX needs a major redesign. A backup application should prioritize user control, transparency, reversibility, and safety above convenience.

At minimum, please consider adding a "Preview / Choose what to restore" step and an explicit confirmation before making any changes to the system. Also, please provide a straightforward way to cancel or undo a restoration that has already been initiated.

I hope this feedback is taken seriously, because the current behavior can very easily result in users unintentionally overwriting or contaminating configurations on a new Linux installation.

[vikdevelop]

Thank you for the detailed report. However, some parts of the behavior you describe do not match how Save Desktop 4.1 currently handles imports, so I would like to clarify what happened before drawing any conclusions.

In Save Desktop 4.1, the import selection dialog is normally displayed when the archive contains selectable items. The import can also always be cancelled using the "Cancel" button before anything is applied.

There is one exception in 4.1: if an archive contains only desktop-environment-specific directories and "General/dconf-settings.ini", there is currently no separate selectable item for these contents, so the selection dialog is not displayed. This is addressed in 4.2 by introducing a "System settings" option, which will allow these settings to be explicitly included or excluded.

Desktop-environment-specific configuration is also not blindly restored across different DEs. For example, when running Save Desktop under KDE, "~/.config/cosmic" is not restored.

Because of this, I am currently unable to determine how the behavior described in the issue occurred. In particular, I would like to understand how the Flatpak restoration was started without the corresponding selection step.

Could you please provide:

• the exact Save Desktop version you were using;
• the contents of the backup archive (a list of its files/directories is sufficient).

With those two pieces of information, I should be able to determine whether this was caused by the archive contents, an older version of Save Desktop, or an actual bug in the current import process.