feat(gui): implement automatic Dry-Run / Preview Mode reporting

[jtrag]

Hello,

I am a new contributor, and I was fixing/modifying some things about BackInTime for myself today, but then I decided to do it as a contribution to the official project and add a much-wanted feature while I was at it (I added dry run). I have tested everything, and it works 100%. Screenshots shouldn't be necessary for these additions/fixes since nothing about the GUI itself has changed. I hope this helps others to continue to use BackIntime for many years to come!

• Added a 'Dry Run / Preview Mode' toggle under 'Expert Options' (utilizing rsync --dry-run).
• The dry-run executes realistically but skips writing out new files to the backup drive.
• Modified asynchronous backup state loop in app.py to intercept dry-run completion and automatically spawn the Backup Log View popup window. This provides users an immediate, clear report of which files would have been copied or modified.
• Reworded generic snapshot completion message to clearly state "Dry run complete, no backup created" when running cleanly in this mode.

Authored by @jtrag (https://github.com/jtrag).
☕ BuyMeACoffee: https://buymeacoffee.com/jtrag
💙 PayPal: https://paypal.com/donate/?business=DN9W5GQ638WPQ

Might fix #248

[buhtz]

Hello James,
On behalf of the team, thank you for your contribution and taking the time to improve Back In Time. We appreciate it.

This is a good start. But some aspects needs discussion and modification.

1. The --dry-run option is never attached to the rsync call and therefor has no effect. Am I right?

2. A screenshot would have helped because you modified the GUI. In my opionen the Expert Options tab is not a good location for that option. I would suggest to use the "Create Backup" button in the main windows toolbar and add a third entry to it. What do you think? Any other suggestions or ideas?

3. Keep in mind that the target audience of Back In Time are end users. They should be able to use BIT without knowing something about the underlying processes, e.g., rsync. Because of that the term "dry run" is IMHO not appropriate. I am not an English native speaker, so I am open for suggestions. But maybe simulation would fit better? That --dry-run is used in the back can be added in a tooltip.

4. Please consider running the unit tests including the linters. That tests are skipped if no linters present. Please install ruff and pylint, additionally flake8 and codespell would be nice also.
   I like it that the log window pops open immediatly after the dry run. I also appreciate that you considered such details like the status bar message.

Best,
Christian

EDIT

Please check the discussion in #248 to get an idea of other users needs.

[jtrag]

Hello James, On behalf of the team, thank you for your contribution and taking the time to improve Back In Time. We appreciate it.

This is a good start. But some aspects needs discussion and modification.

1. The `--dry-run` option is never attached to the `rsync` call and therefor has no effect. Am I right?

2. A screenshot would have helped because you modified the GUI. In my opionen the Expert Options tab is not a good location for that option. I would suggest to use the "Create Backup" button in the main windows toolbar and add a third entry to it. What do you think? Any other suggestions or ideas?

3. Keep in mind that the target audience of Back In Time are end users. They should be able to use BIT without knowing something about the underlying processes, e.g., rsync. Because of that the term "dry run" is IMHO not appropriate. I am not an English native speaker, so I am open for suggestions. But maybe simulation would fit better? That --dry-run is used in the back can be added in a tooltip.

4. Please consider running the unit tests including the linters. That tests are skipped if no linters present. Please install ruff and pylint, additionally flake8 and codespell would be nice also.
   I like it that the log window pops open immediately after the dry run. I also appreciate that you considered such details like the status bar message.

Best, Christian

EDIT

Please check the discussion in #248 to get an idea of other users needs.

Hi Christian,

I apologize for the delay. I am currently working on this, and I am changing it to say Simulation instead of Dry Run, and placing it in the "Create Backup" button menu. I am also adding the following features:

Simulation Mode:

• WILL pass the --dry-run flag to rsync
• will write a file to the backup destination, such as "Simulation-Results.txt", with a detailed list of all files that would have been written, file ownership/permissions, errors, etc.
• It will log any files that weren't copied due to permission errors so that users can easily identify such issues.
• There will be an option in the autoremove/backup retention settings that users can tick/turn on to keep Simulation backups. The default would be to automatically delete them according to the retention/autodelete settings.
• Simulation backups will be clearly labeled as Simulation backups in the list of backups.
• Simulation backups will NOT be able to be restored, so that users do not restore an empty simulation backup by accident, causing data loss.

Other features:

• Additional settings for commonly used rsync flags in the Expert Options tab with tooltips that have detailed info for beginners to fully understand what the options are for.
• rsync command preview in Expert Options tab that shows the rsync command that will be run by BackInTime, according to the current settings that you have set in BackInTime (I should be able to make this update dynamically as you tick options on/off and it will be displayed in a box at bottom of the Expert Options tab, that users can easily copy the rsync command that will be run via right click).
• Status bar fix so that it always shows the real live status of what it is doing. If doing nothing, the status bar will show the last backup that ran, whether or not it was successful, the amount of time that the last backup took to complete, and the free space at the backup location. This will ensure that the status bar always clears to the default when not actively doing something, and only displays status for current activities, so that old status messages don't stick there like it does sometimes currently. It will also provide some useful information that is available at first glance on the GUI.

I will also be running the unit tests/linters, etc., and already have a virtual environment setup with those installed and ready to go.

I have to tend to my son, who just got surgery, until Sunday, and then I'll be working on this more. I will keep you posted. I'm sharing what I am planning for now so that you know that I am still on top of things, and so that we can discuss these changes beforehand. I will get this done as soon as I possibly can. It is a great time to revamp BackInTime, with Linux growing in popularity rapidly. Lots of new users will be looking for a backup solution for Linux, and BackInTime has been around for a long time. It just needs a few things to modernize it and make it more beginner/user-friendly, and it will be the perfect solution :)

I think this pretty much covers the list of changes, etc. that I have planned for this so far, but if I think of anything else, or missed anything, I'll post a reply or just edit this post.

If you or anyone else has any feedback on any of this, it would be greatly appreciated, as it will help me to help make BackInTime the best possible backup solution for Linux that it can be :)

Thanks for allowing me to contribute and being open to my edits/improvements, etc. This is the beauty of open-source software :)

I have a spinal cord injury myself and have a lot going on, but my son should be going back with his mom tomorrow, and I should have a lot of free time in the next few weeks, so I will be able to get this done. I apologize ahead of time if things take me a bit longer due to my injury, etc., and I will get this stuff done. Likely on Monday of this coming week <3

[buhtz]

Hello James,

your comment becomes a bit chaotic and touches several topics that are not related to this PR. Please open an issue for each of the topics. This makes it easier to discuss and easier for others to follow discussions.

* will write a file to the backup destination, such as "Simulation-Results.txt"

Isn't there the regular log file?

* There will be an option in the autoremove/backup retention settings that users can tick/turn on to keep Simulation backups.  The default would be to automatically delete them according to the retention/autodelete settings.

* Simulation backups will be clearly labeled as Simulation backups in the list of backups.

* Simulation backups will NOT be able to be restored, so that users do not restore an empty simulation backup by accident, causing data loss.

I am not sure if I understand. A simuliaton is not a backup so it should not appear in the timeline widget and is not relevant to restore or autodelete feature. It is a one-shot thing.

I would say that it would be enough if the log-window pops up after the simulation so the user can see the results. The results don't need to be persistent.

* Additional settings for commonly used rsync flags in the Expert Options tab with tooltips that have detailed info for beginners to fully understand what the options are for.

"commonly used rsync flags"? Would it mean you add new flags? Please don't.

* rsync command preview in Expert Options tab that shows the rsync command

That is out of scope of BIT. BIT is for end-users. Technically it might be an rsync-frontend but it shouldn't behave like such. Someone can see the debug output if the rsync command is of interest.

* Status bar fix so that it always shows the real live status ...

The status bar has potential for improvement. The ideas are not bad. But lets discuss them in a separate issue in more details.

If you or anyone else has any feedback on any of this

The mailing list is always a good place to discuss needs and wishes of others users.

Best wishes,
Christian

[jtrag]

Hello James,

your comment becomes a bit chaotic and touches several topics that are not related to this PR. Please open an issue for each of the topics. This makes it easier to discuss and easier for others to follow discussions.

* will write a file to the backup destination, such as "Simulation-Results.txt"

Isn't there the regular log file?

* There will be an option in the autoremove/backup retention settings that users can tick/turn on to keep Simulation backups.  The default would be to automatically delete them according to the retention/autodelete settings.

* Simulation backups will be clearly labeled as Simulation backups in the list of backups.

* Simulation backups will NOT be able to be restored, so that users do not restore an empty simulation backup by accident, causing data loss.

I am not sure if I understand. A simuliaton is not a backup so it should not appear in the timeline widget and is not relevant to restore or autodelete feature. It is a one-shot thing.

I would say that it would be enough if the log-window pops up after the simulation so the user can see the results. The results don't need to be persistent.

* Additional settings for commonly used rsync flags in the Expert Options tab with tooltips that have detailed info for beginners to fully understand what the options are for.

"commonly used rsync flags"? Would it mean you add new flags? Please don't.

* rsync command preview in Expert Options tab that shows the rsync command

That is out of scope of BIT. BIT is for end-users. Technically it might be an rsync-frontend but it shouldn't behave like such. Someone can see the debug output if the rsync command is of interest.

* Status bar fix so that it always shows the real live status ...

The status bar has potential for improvement. The ideas are not bad. But lets discuss them in a separate issue in more details.

If you or anyone else has any feedback on any of this

The mailing list is always a good place to discuss needs and wishes of others users.

Best wishes, Christian

You're right. Let me take a step back here for a minute and do this one thing at a time. I will be working on this simulation feature and getting this completed so that we can get this and the Wayland issue fix merged first. Then we can discuss further additions/improvements, etc..

I apologize for being so messy and chaotic. I appreciate you pointing that out. I have had a lot going on, but I should have a lot more time this week to focus on this. I will address the Simulation feature for now. Then work on other things that you and the community agree to.

To answer your question about the simulation backups showing in the list, they will show there with a folder to show that it was able to write to the location, and in that location, it will have a file with a highly detailed log of the simulation backup results. But if you prefer that they don't show in the list or write files at all, I'll code it that way. I will also not add additional rsync commands. It is usually best to keep things simple when possible anyway :) I will get the simulation stuff sorted and submit a pull request asap. I apologize. It has been a rough past week or so for me. And had a sudden medical emergency to deal with. I'll post an update soon :) Cheers :D

[buhtz]

Hello James,
I would suggest to wait working on this or other PRs until #2449 is merged. I am in the middle of re-writing the mount system from scratch. That modifies nearly every file in the repository. This is because of the not so ideal state of the codebase.
It would create heavy merge conflicts with your modifications.

Sorry.

Regards,
Christian

• Announcement on bit-dev mailinglist
• Announcement on Mastodon

[jtrag]

Okay, I will hold off on working on this until you are done with the other PRs. It would probably be best at this time anyway, as I have not been doing so well healthwise due to a spinal cord injury in the neck, which even affects my ability to think/concentrate (or I probably would have noticed that this would cause such conflicts and realized this myself hehe), but I am getting it to calm down some. I'm looking forward to having a new, improved BackInTime to use :) I'll be happy to contribute later. I'll work on a few projects of my own that I wanted to start, in the meantime, and just run a fixed version of BackInTime locally with the Wayland fix for now. Thanks for everything, Christian :) Cheers!