Request: GUI for Changes Persistence

[rych]

When using changes=EXIT:/porteus the changes are instead being written into /mnt/live/memory/changes.

At shutdown the changes-commit saves certain changes into a persistent storage according to the /etc/changes-exit.conf.

It would be nice to keep it clean and to save only specific files without all the "junk" the system and apps will recreate on the next reboot.

In a perfect world, at shutdown, when a non-ignored content is found inside /mnt/live/memory/changes, meaning something is trying to amend our persistence state, ...a GUI window with folder tree and check-boxes, would popup asking me which changes I want to commit or ignore, once or forever.

Otherwise I constantly have to watch my /changes folder post-factum for the junk that didn't need to be persistent. I then remove it from /changes and add an ignore rule into /etc/changes-exit.conf.

[Ed_P]

watch my /changes folder post-factum for the junk that didn't need to be persistent. I then remove it from /changes and add an ignore rule into /etc/changes-exit.conf.

I find when I update my ignore rules the unwanted changes that were previously saved and restored when I rebooted with my changes folder get deleted when I exit.

[rych]

I find when I update my ignore rules the unwanted changes that were previously saved and restored when I rebooted with my changes folder get deleted when I exit.

Really? At the moment I do have certain files and folders in my permanent /changes that are not even mentioned in the /etc/changes-exit.conf. You're saying that if I list it explicitly with !/var/somefile the existing old copy also gets removed from /changes? I'm going to have to experiment.

[ncmprhnsbl]

n a perfect world, at shutdown, when a non-ignored content is found inside /mnt/live/memory/changes, meaning something is trying to amend our persistence state, ...a GUI window with folder tree and check-boxes, would popup asking me which changes I want to commit or ignore, once or forever.

it's a nice idea, the trickiest bit is how to trigger this at shutdown whilst still in the gui.
easy enough to do with openbox, since it logout dialog is just a script, that could be modified to handle this contingency(and spawn said dialog) , but with the other DEs it's a bit hard to hack the builtin dialogs..
conceivably, they could be bypassed and replaced with something compliant ...maybe..
alternatively, something uglier on the shutdown console might be easier to implement.

[Ed_P]

alternatively, something uglier on the shutdown console might be easier to implement.

When shutting down, users want the system to exit and save any changes meant to be saved, ASAP. Going thru a menu to decide what to save, where to save, etc., is not a good approach to the shutting down process. IMO

[rych]

the trickiest bit is how to trigger this at shutdown whilst still in the gui

OK then, how about, while GUI user is still logged in, they could run a Persistence Manager that examines the current, live snapshot of /mnt/live/memory/changes and allows to tick the changes they want to become persistent by adding entries into an initially empty /etc/changes-exit.conf under the hood? Of course, we can just continue doing it manually.

When shutting down, users want the system to exit and save any changes meant to be saved, ASAP.

Of course, my words exactly last time we were discussing changes-commit if you recall. But now I'm thinking what is really "meant to be saved"? A lot of polluting junk is getting saved that is reproducible next reboot, and is should rather be recreated. As for ASAP escape: for GUI there would be a Quit button with a default behavior. For console "save all" or "reject all" changes. But you're right, normally we don't want to be prompted with any questions during shutdown. We'd rather be surprised next time realizing some settings or customizations had not be saved. Or deal with ever increasing, polluted /changes.

The in-session graphical Persistence Manager app proposed above might serve to give user a bit of control and awareness. It took me several years as a Porteus user to discover the /etc/changes-exit.conf

[rych]

I find when I update my ignore rules the unwanted changes that were previously saved and restored when I rebooted with my changes folder get deleted when I exit.
Really?

Nope, I don't confirm this. For example, just amending /etc/changes-exit.conf with

!/dev

doesn't delete an existing /dev junk in your /changes: we have to manually go into /changes and remove /dev. And then no need for /dev mentioning in /etc/changes-exit.conf. The ! prefix is for exceptional not-saving of certain portions, it won't delete it if it's already there.

[rych]

the trickiest bit is how to trigger this at shutdown whilst still in the gui

then, how about, while GUI user is still logged in, they could run a Persistence Manager that examines the current, live snapshot of /mnt/live/memory/changes

OK, a different idea. The Persistence Manager daemon monitoring /mnt/live/memory/changes could alert the user by turning its tray icon "red" when there are new proposed changes to our system. Clicking on it before shutting down, choosing the meaningful ones, the GUI user can have a fine control over persistence if they wish. Otherwise they can always just shut down quickly no questions asked, by default either saving all or rejecting all.

[Rava]

I don't confirm this. For example, just amending /etc/changes-exit.conf with

Code: Select all

!/dev

doesn't delete an existing /dev junk in your /changes: we have to manually go into /changes and remove /dev. And then no need for /dev mentioning in /etc/changes-exit.conf. The ! prefix is for exceptional not-saving of certain portions, it won't delete it if it's already there.

I do not use save changes on exit (I save everything manually and want the system to ignore all other changes) but... as I understand how /etc/changes-exit.conf should work, should not add

Code: Select all

!/dev

delete aka ignore all in /dev ?