Mistakes in GUI backup, please fix (Pupsave Backup)

[dimkr]

Making a pull request at https://github.com/puppylinux-woof-CE/woof-CE

https://github.com/puppylinux-woof-CE/w ... ibutor-101

(But going through GitHub's tutorials or having some basic familiarity with git is of course better)

[geo_c]

Not sure if I understand well the discussion about restoring, but isn't "restoring" already automatically provided with the option at boot to choose for different saves ? (i.e. for first boot save made and optionally for backed up saves (if there are any))

Yes I think we're kind of going in circles a bit.

It started with the idea that if you have a compressed backup utilility, there might naturally be a utility to "restore it"

After all, the whole point of the OP is the lack of user friendliness.

So I made the comment, that since the compressed folder has the same name as the original save it was copied from as you discovered and pointed out, then uncompressing it in the directory of origin would of course overwrite the original. In essence being a "restore function" provided that you weren't running in a pupmode directly writing to the loaded save, which would cause major issues.

And of course that's not a good setup. So you've rewrititten the script to name the folder inside the compressed file with a timestamped name. Major improvement.

Text in the gui explaining a few things should do to make the utility more user-friendly.

The choice at boot is of course good enough for those that understand how it all works. I'll leave it at that.

[mikewalsh]

Slightly "off-topic" here, perhaps.....but given the subject matter - about restoring from backups, AND about GUIs (I like my GUIs! ) - I thought I'd show y'all what my own routine has evolved into :-

Nowt special, but it makes what used to be a chore into a more pleasant experience.....AND it's all good scripting practice for me at the end of the day.

Essentially, every 10 days or so, I run a simple copy/paste operation on the "kennels" - the directory containing all my frugal installs.....straight through from start to finish, one sub-directory after another (the whole install, 'save' & all).

==================================

The backups have been scripted for a while. This thread got me thinking, though. I've always restored manually on a per-Pup basis; delete, copy across, using a pair of open ROX-filer windows, as & when needed. I thought I'd have a go at automating the restore side of things to some degree, so I've been messing around with this for much of today. And that's allowed me write a GUI to combine both operations together, so it can all be run from the same location.

(It's very much a custom job. It's easy enough to edit each main script, to add/remove Pups as & when the kennels change.....but it's NOT something I could easily turn into a publicly-available package. However, I'm happy with it, and it 'works' for ME).

Mike.

[geo_c]

(It's very much a custom job. It's easy enough to edit each main script, to add/remove Pups as & when the kennels change.....but it's NOT something I could easily turn into a publicly-available package. However, I'm happy with it, and it 'works' for ME).

Mike.

Very nice, enjoyable hearing you talk. Now, if I can just remember to hear your posts read in your own voice as I read them, it will improve my connection with what you're saying!

You definitely have the most personalized puppy system I've ever seen. And I found your collection of pups an intersting lineup, no F96, no Bookworm, mostly older, what many of us would considered "retired," puppies. Amazing you keep them working well enough to maintain.

I thought you were using gxmessage just by the look of the dialog boxes. I've used gxmessage for gui scripts myself. I don't know if it's still maintained or not. But I do know how to create interactive choices with it.

The thing I tried to communicate earlier in this thread, and I think this video illlustrates well, is that when it comes to portable linux OS's, there is no "universal" setup that makes managing installs and persistance a one-size-fits-all affair. The utilities to create backups must, due to the portable nature of the OS, be somewhat open ended. I personally wouldn't want to "restore" or "roll-back" at all, I would probably want to keep the current save, even if corrupted, to troubleshoot it or grab files that might still be in the save that I would like to transfer. Pups and Forum Distros are setup perfectlly to do just that kind of thing. We have multiple ways of switching persistant saves in and out and cherry picking the directories while working in other loaded saves.

Most of the experienced forum members most likely have multiple OS's installed an a given machine, and manually manipulate these saves from one of the other OS's. I know I do, it's easier in the long run. Shutdown, bootup another OS, copy, delete, paste, and reboot. My KLV-spectr boots in under 10 seconds to a settled desktop. It would make no sense, given the amount of control one has manipulating saves manually, to try and switch out current upper_changes using a script while running a live OS. Even though @fredx181 has written an excellent backup/restore script for KL's in which the upper_changes are backed up and can be restored from the same script, loading at the next boot, I personally never use the restore function of it. I use the backup side of it continually. In fact I build systems by doing a psuedo-full install and backing up the upper_changes (which then contain the entire filesystem of the OS) and squashing it, creating a compressed read-only filesystem.

So when it comes to pupsave-backup, it should probably conform to the linux standard, do one thing and do it well, perhaps with a little more detail in the dialog as to how the backup save is to be treated for future use.

[mikewalsh]

@geo_c :-

I'm surprised you like the sound of my voice! I think I sound dreadful when recorded.....

Yes, I do have a liking for "older" stuff. I missed so much older stuff when it was first around - due to life getting in the way - and I'm kind of re-discovering them for the first time. I also have a liking for seeing just how far I can push the envelope with older OSs, and am frequently surprised by just what many of 'em ARE capable of.

Also - though I hate to say it, and will no doubt be castigated for doing so! - I find that older Puppies are just so much more "fun" than some of the newer ones, despite being so quirky in many ways. That's part of their charm, as far as I'm concerned....

TBH, most of the older ones are kept 'safer' by running many of the internet-facing apps from a much newer chroot; browsers, natch; email clients, and various other bits'n'bobs. And it keeps them viable as daily drivers, since so many of us spend the greater part of our time on-line. I know I do; there's hardly anything that doesn't have either a web-app or online equivalent of some kind these days. The portables come in very handy for this, and usually just run from the chroot's /opt, with a relative link into /usr/bin; as for the host chroot 'launchers', I make use of and simply modify those provided by watchdog from back when he proffered the chrooted PaleMoon browser, at the time when Darry & I were playing around with his customized Puppy 4.3.1.1, the "Phoenix". Damn, that thing was fun..!

Most folks are obsessed with security, fixes & patches, and endlessly keeping everything bang up-to-date. With the ease of backing-up and restoring, such stuff has never really bothered me.....though as "staff", I'm well aware I'm not really 'playing the game' by recommending everyone to always use the very newest releases all the time. I have an install of the current release of BookwormPup, though I really haven't done much with it. I've never been a fan of Synaptic, and I see it still hasn't improved any. It may get more use over the next year or so. It almost certainly will, as browsers gradually get beyond my current 'workarounds' for older Pups. We'll see how it goes.

I use a Bionicpup chroot ATM for 32-bitzers (Tahrpup became Xenialpup, which then became Bionicpup), and a Fossapup chroot for 64-bitzers (Xenialpup -> Bionicpup -> Fossapup). I periodically upgrade these as time passes, probably every 18 months or so, so that internet -facing stuff stays somewhat more secure. For other apps, most of the native ones - if they work fine, and do what I want - I leave 'em the hell alone. If it works, why try to "fix" it? Bigpup says this often, and I've always agreed with his viewpoint on this.

As for highly-customized, well; I take the view that I'm the one who has to look at the things all day long, so I don't mind dolling 'em up with plenty of eye-candy, along with all kinds of shortcuts & easier ways to access and do things. Yes, I DO like my GUIs, and the more practice I get with YAD & gxmessage, etc, the easier it all becomes. It's amazing how often I find myself recycling the same snippets of code over and over again. They work, they do what I want, so.....I re-use 'em.

I'm a dinosaur at heart, I don't mind admitting it.....and to me, Puppy IS endlessly customisable, once you understand how stuff works. Barry really knew what he was doing when he picked ROX & JWM for a desktop combo. As a child of the early 60s - and a Sagittarian to boot! - what else d'you expect of me..???

Mike.

[bigpup]

Drop the idea of a backup save restoring a broken save. All it can do is replace.

A save backup is a copy of a save at a specific point in time.
A copy of what was in the save at that specific point in time.

A save backup can only totally replace a save.
When used, it is now the save as it was at the time the backup was made.

As Puppy Linux now works.
Being able at boot up to have the normal save and backup saves listed to choose from.
You simply choose which one to use.
If you do not want to see backups to select. Place them in a location the boot process will not see them. (not the same location as the normal save)

Just because a save is broken and not working correctly. (keeping Puppy from working correctly)
you may want to access it by a file manger and pick stuff out of it. (new documents, pictures, downloaded stuff, etc....)
In Puppy you can left click on a save file or folder and access it's contents.

[williwaw]

If you do not want to see backups to select. Place them in a location the boot process will not see them. (not the same location as the normal save)

the idea was that the backup utility, by compressing all backups by default, would remove them from view in the list of saves at boot time without having to mange them manually in a different directory.

But if they could be visible in the backup utility and uncompressed with a button press when selected, then an uncompressed copy would available at bootime. The compressed backup would remain. At present, the recomendation is to remove the BKPXXXXX extension from an uncompressed backup to restores the the original, but that is not quite right unless one wants to overwrite the original or rename the backup to something else. Then one now needs to manually copy the renamed backup or remember to run the utility to make a new backup immediately at the next boot if the backup is to be retained.

A few simple improvements could let this app help manage backups more effectively. Another improvement might be to allow the user to name the backups as they choose. Just suggestions thrown out there while a few of us are discussing some simple changes.

[greengeek]

The backups have been scripted for a while. This thread got me thinking, though. I've always restored manually on a per-Pup basis; delete, copy across, using a pair of open ROX-filer windows, as & when needed. I thought I'd have a go at automating the restore side of things to some degree, so I've been messing around with this for much of today. And that's allowed me write a GUI to combine both operations together, so it can all be run from the same location.

(It's very much a custom job. It's easy enough to edit each main script, to add/remove Pups as & when the kennels change.....but it's NOT something I could easily turn into a publicly-available package. However, I'm happy with it, and it 'works' for ME).

If you ever formalise your scripts or method I would be very keen to have any feedback here if you have time.
(Not relative to save files - just relative to backups in general)

[mikewalsh]

@greengeek :-

Heh. Nice idea as it is, Ian, my scripting isn't anywhere remotely near the stage where I could put together something that would work for everybody.

My scripts are a mess. They're not tidy. I don't use accepted layout, and for this kind of thing I would probably need to learn about half-a-dozen new concepts in order to do everything efficiently (which I no longer have the time to do). I throw things together, quickly, that work for ME personally, but I'd be embarrassed to share them...

I think I'll stick to what I know!

Mike.

[Governor]

If you do not want to see backups to select. Place them in a location the boot process will not see them. (not the same location as the normal save)

the idea was that the backup utility, by compressing all backups by default, would remove them from view in the list of saves at boot time without having to mange them manually in a different directory.

But if they could be visible in the backup utility and uncompressed with a button press when selected, then an uncompressed copy would available at bootime. The compressed backup would remain. At present, the recomendation is to remove the BKPXXXXX extension from an uncompressed backup to restores the the original, but that is not quite right unless one wants to overwrite the original or rename the backup to something else. Then one now needs to manually copy the renamed backup or remember to run the utility to make a new backup immediately at the next boot if the backup is to be retained.

A few simple improvements could let this app help manage backups more effectively. Another improvement might be to allow the user to name the backups as they choose. Just suggestions thrown out there while a few of us are discussing some simple changes.

I think we can agree that compression of backups is not as as important as it once was, ie. when we were using floppy disks. I was about to suggest removing the compressed feature completely, but your idea sounds like a game changer.
I wait in anticipation until the clever folks figure this out.

[wizard]

@Governor

I think we can agree that compression of backups is not as as important as it once was, ie. when we were using floppy disks. I was about to suggest removing the compressed feature completely

Would disagree with this since those using Puppy from a USB flash, SDcard, small HDD, or small HDD partition will still want and welcome compression.

wizard

[mikewalsh]

@Governor

I think we can agree that compression of backups is not as as important as it once was, ie. when we were using floppy disks. I was about to suggest removing the compressed feature completely

Would disagree with this since those using Puppy from a USB flash, SDcard, small HDD, or small HDD partition will still want and welcome compression.

wizard

@Governor / @wizard :-

Ayup. I must concur with m'colleague here.

My current hardware may well be capable of doing anything I want.....tons of RAM, storage by the bucket-full.....but it wasn't so many years since I was running exactly the kind of hardware he's describing. Both were DDR1-era, which gives you a hint as to just how old they were.....and the limitations were inherent to the hardware standards of that period in time.

(Modern CPUs alone, sipping on a mere dribble of power & running as cool as a cucumber, will run rings around processors from that earlier period in time that used to guzzle the stuff AND run hot enough to heat your room! And that's but a single aspect of how hardware has evolved...)

You couldn't use more than 4 GB RAM - even if you wanted to - 'cos mobos/chipsets of the day simply didn't support it.....and if you had owt bigger than a 160 GB HDD, you were at the top of your game. I don't think there was anything much bigger available at the time - the average HDD was around 80GB in those days - and 'basic' SATA SSDs were still just a twinkle in some engineer's eye back then, never mind all this ultra-fast, high-capacity NVMe storage that's now available. THAT was firmly in the realms of fantasy back then!

My desktop jumped straight from DDR1 to DDR4, though the last two lappies (both Dell Latitudes!) have given me a "look-see" into what DDR2 and DDR3 RAM performance is like. No, such compression is probably not as important to most people these days as it once was, but there's yet plenty of folks out there still running such older hardware - whether by choice OR necessity - who DO deserve to be "catered-for".

Mike.

[Governor]

@Governor

I think we can agree that compression of backups is not as as important as it once was, ie. when we were using floppy disks. I was about to suggest removing the compressed feature completely

Would disagree with this since those using Puppy from a USB flash, SDcard, small HDD, or small HDD partition will still want and welcome compression.

wizard

@Governor / @wizard :-

Ayup. I must concur with m'colleague here.

My current hardware may well be capable of doing anything I want.....tons of RAM, storage by the bucket-full.....but it wasn't so many years since I was running exactly the kind of hardware he's describing. Both were DDR1-era, which gives you a hint as to just how old they were.....and the limitations were inherent to the hardware standards of that period in time.

(Modern CPUs alone, sipping on a mere dribble of power & running as cool as a cucumber, will run rings around processors from that earlier period in time that used to guzzle the stuff AND run hot enough to heat your room! And that's but a single aspect of how hardware has evolved...)

You couldn't use more than 4 GB RAM - even if you wanted to - 'cos mobos/chipsets of the day simply didn't support it.....and if you had owt bigger than a 160 GB HDD, you were at the top of your game. I don't think there was anything much bigger available at the time - the average HDD was around 80GB in those days - and 'basic' SATA SSDs were still just a twinkle in some engineer's eye back then, never mind all this ultra-fast, high-capacity NVMe storage that's now available. THAT was firmly in the realms of fantasy back then!

My desktop jumped straight from DDR1 to DDR4, though the last two lappies (both Dell Latitudes!) have given me a "look-see" into what DDR2 and DDR3 RAM performance is like. No, such compression is probably not as important to most people these days as it once was, but there's yet plenty of folks out there still running such older hardware - whether by choice OR necessity - who DO deserve to be "catered-for".

Mike.

@peebee
At least the extra line of text could be added as discussed. Something like, "Note: Compressed pupsave backups must be decompressed to be usable."

A couple of people have mentioned complications with correct functioning of subsequent uncompression, should these issues be addressed?

When a user gets to the dialog box [Pupsave Backup-Compress] and is asked if they want to compress the backup file, the user can choose [Yes] or [No] but there is no [Cancel] button, and closing the dialog box does not cancel the operation. It is rare that a user is not allowed to change their mind and cancel when in a dialog box. How difficult would it be to take a cancel button routine and stick it in the appropriate place so there is [Cancel] [No] [Yes], and remove the X (close dialog box)?

[fredx181]

...
When a user gets to the dialog box [Pupsave Backup-Compress] and is asked if they want to compress the backup file, the user can choose [Yes] or [No] but there is no [Cancel] button, and closing the dialog box does not cancel the operation. It is rare that a user is not allowed to change their mind and cancel when in a dialog box. How difficult would it be to take a cancel button routine and stick it in the appropriate place so there is [Cancel] [No] [Yes], and remove the X (close dialog box)?

And what should it do then in your opinion, cancel the whole backup operation or only cancel the compressing ?
edit: if it should cancel the whole backup operation, then I'd say better call it "Quit".

[Governor]

...
When a user gets to the dialog box [Pupsave Backup-Compress] and is asked if they want to compress the backup file, the user can choose [Yes] or [No] but there is no [Cancel] button, and closing the dialog box does not cancel the operation. It is rare that a user is not allowed to change their mind and cancel when in a dialog box. How difficult would it be to take a cancel button routine and stick it in the appropriate place so there is [Cancel] [No] [Yes], and remove the X (close dialog box)?

And what should it do then in your opinion, cancel the whole backup operation or only cancel the compressing ?
edit: if it should cancel the whole backup operation, then I'd say better call it "Quit".

Good point. In this case I would suggest that [Cancel] be used to return to this screen:

Pupsave backup dialog.jpg (34.1 KiB) Viewed 832 times

When at the compress Y/N dialog, does anyone else think it odd that even if you right click the icon in the taskbar and choose "kill" the window, it has no effect on the procedure? Kill usually means kill, right?

Pupsave Backup-Compress.png (215.57 KiB) Viewed 831 times

[wizard]

Take a look here for a Puppy backup restore utility:
viewtopic.php?t=13697

wizard

[TerryH]

When at the compress Y/N dialog, does anyone else think it odd that even if you right click the icon in the taskbar and choose "kill" the window, it has no effect on the procedure? Kill usually means kill, right?

It's not odd at all. How can you kill something after it has completed. The back has completed. The compress is an additional step.

Edit: @Governor My apologies for my erroneous post, which @fredx181 has pointed out in subsequent post is incorrect.

[Governor]

@fredx181

When at the compress Y/N dialog, does anyone else think it odd that even if you right click the icon in the taskbar and choose "kill" the window, it has no effect on the procedure? Kill usually means kill, right?

It's not odd at all. How can you kill something after it has completed. The back has completed. The compress is an additional step.

Ok, so what I find confusing is the reverse logic in the event order. I thought the backup was being prepared (not written to disk), and then if the user cancelled, the created backup discarded.
A user is asked if he wants to compress a backup after the backup has been created.
In my mind, it would be normal procedure to have the compress dialog BEFORE the backup is created, so the user can choose beforehand, instead of after the fact.

In either case, it is very important that the user is informed that the compressed backup will not be usable.
The backup directory location can be chosen by the user. Why can't the user customize the backup filename, while being informed which part of the backup name must not be changed? Or, even better, the protected part of the filename be locked so it cannot be changed?

Very important: Why not inform the user which folder must be used in order for the backup to appear in the boot menu?

Another possibility:
Instead of requiring a particular filenaming convention, how would it be to place an innocuous "flag" near the top of each backup file when it is created. One flag could indicate whether it is an uncompressed backup file and another flag could indicate if it is a compressed backup file. I doubt is would take much more time to check for a flag near the top of a file then to check for a specific filename.

[fredx181]

When at the compress Y/N dialog, does anyone else think it odd that even if you right click the icon in the taskbar and choose "kill" the window, it has no effect on the procedure? Kill usually means kill, right?

It's not odd at all. How can you kill something after it has completed. The back has completed. The compress is an additional step.

Ok, so what I find confusing is the reverse logic in the event order. I thought the backup was being prepared (not written to disk), and then if the user cancelled, the created backup discarded.
A user is asked if he wants to compress a backup after the backup has been created.
In my mind, it would be normal procedure to have the compress dialog BEFORE the backup is created, so the user can choose beforehand, instead of after the fact.

That is the case already, the compress dialog does appear BEFORE the backup is created. (edit: i.e. not true what Terry said)

Btw, I see a logic in the fact that when you click close-box [X] at the yes/no compression dialog that it still continues with the backup (uncompressed then), as the script assumes that you don't want compression. (same as 'No' actually).

Just thinking, perhaps you want to be able to completely stop backup creation at any time (e.g. a 'Quit' button at all dialogs), something like this:

Screenshot(1).png (35.96 KiB) Viewed 728 times

[Governor]

It's not odd at all. How can you kill something after it has completed. The back has completed. The compress is an additional step.

Ok, so what I find confusing is the reverse logic in the event order. I thought the backup was being prepared (not written to disk), and then if the user cancelled, the created backup discarded.
A user is asked if he wants to compress a backup after the backup has been created.
In my mind, it would be normal procedure to have the compress dialog BEFORE the backup is created, so the user can choose beforehand, instead of after the fact.

That is the case already, the compress dialog does appear BEFORE the backup is created. (edit: i.e. not true what Terry said)

Code: Select all

• PUPMODE=13
 • PDEV1='nvme0n1p2'
 • DEV1FS='ext3'
 • PUPSFS='nvme0n1p2,ext3,/Bookworm64_10.0.6/puppy_dpupbw64_10.0.6.sfs'
 • PUPSAVE='nvme0n1p2,ext3,/Bookworm64_10.0.6/dpupbw64save-2024-06-25-basic'
 • PMEDIA='usbflash'
 

To me, it looked like the backup was created before the compress dialog.

Saving session to folder.JPG (31.53 KiB) Viewed 698 times

Now, after your input, I am thinking that Puppy is updating my pupsave on disk before saving the backup. Is that correct, and can the on-screen message be made less confusing, ie more specific? This may seem redundant, but surely, it is not a big deal to change the existing on-screen blurb to something more useful.
Maybe something like this: "Saving your current session to disk, before creating backup." It would be comforting.

Btw, I see a logic in the fact that when you click close-box [X] at the yes/no compression dialog that it still continues with the backup (uncompressed then), as the script assumes that you don't want compression. (same as 'No' actually).

Just thinking, perhaps you want to be able to completely stop backup creation at any time (e.g. a 'Quit' button at all dialogs), something like this:
Screenshot(1).png

It would be great to have a dialog box like that!

[Governor]

If you do not want to see backups to select. Place them in a location the boot process will not see them. (not the same location as the normal save)

the idea was that the backup utility, by compressing all backups by default, would remove them from view in the list of saves at boot time without having to mange them manually in a different directory.

But if they could be visible in the backup utility and uncompressed with a button press when selected, then an uncompressed copy would available at bootime. The compressed backup would remain. At present, the recomendation is to remove the BKPXXXXX extension from an uncompressed backup to restores the the original, but that is not quite right unless one wants to overwrite the original or rename the backup to something else. Then one now needs to manually copy the renamed backup or remember to run the utility to make a new backup immediately at the next boot if the backup is to be retained.

A few simple improvements could let this app help manage backups more effectively. Another improvement might be to allow the user to name the backups as they choose. Just suggestions thrown out there while a few of us are discussing some simple changes.

In any case, it is very important that the user is informed that the compressed backup will not be usable.
The backup directory location can be chosen by the user. Why can't the user customize the backup filename, while being informed which part of the backup name must not be changed? Or, even better, the protected part of the filename be locked so it cannot be changed?

Very important: Why not inform the user which folder must be used in order for the backup to appear in the boot menu?

Another possibility:
Instead of requiring a particular filenaming convention, how would it be to place an innocuous "flag" near the top of each backup file when it is created. One flag could indicate whether it is an uncompressed backup file and another flag could indicate if it is a compressed backup file. I doubt is would take much more time to check for a flag near the top of a file then to check for a specific filename.

[fredx181]

@Governor

For testing here's pupsave-backup with many changes as discussed here and more. e.g:

• If compressed, the pupsave inside the archive has now "BKP.<timestamp>" added to the name
• The compression dialog(s) have "Quit" button (will stop the whole process, also when closing the window (clicking [X]))
• More clear messages, e.g. final message about compressed backup how to handle:

  

  Screenshot(2).png (31.86 KiB) Viewed 664 times

  edit: renaming can always be done as long as you keep dpupbw64save- intact, e.g. dpupbw64save-<whatever>

Extract pupsave-backup.tar.gz somewhere and just click on the pupsave-backup script (for testing, no need to replace in /usr/sbin)

pupsave-backup.tar.gz

Extract somewhere and just click on the pupsave-backup script

(4.58 KiB) Downloaded 20 times

I tested thoroughly, IMO it's an improvement altogether, however I still think that most puppy users are fine with the default pupsave-backup (oh.. those nerds ).
(so if this would make it through the WOOF-CE commission ... )

EDIT: Forgot to mention that some of my changes are only for when used save-folder (compressed backup), not (yet) for save-file.
EDIT2: Tested now with savefile and noticed that it's fine too, (creating backup name inside the compressed archive with "BKP.<timestamp>" added to the name)
EDIT3: Mmm.. the savefile backup needs to be renamed by adding .2fs, .3fs or .4fs extension, otherwise not picked up at boot to choose from (also that's the case I think with the default pupsave-backup program).

[wiak]

I tested thoroughly, IMO it's an improvement altogether, however I still think that most puppy users are fine with the default pupsave-backup (oh.. those nerds ).
(so if this would make it through the WOOF-CE commission ... )

I'm confused with threads to do with Pupsave restore all seem to be happening at same time. What is difference to this other stuff by wizard here: viewtopic.php?p=141157#p141157

[Governor]

8<---- snip

I tested thoroughly, IMO it's an improvement altogether, however I still think that most puppy users are fine with the default pupsave-backup (oh.. those nerds ).
(so if this would make it through the WOOF-CE commission ... )

People are often reluctant to accept changes in what they are comfortable with, but once they grow accustomed to an improved version, they will be happy about it, nerd or not. Who is on the WOOF-CE commision, is it a bunch of nerds?

[fredx181]

...
Who is on the WOOF-CE commision, is it a bunch of nerds?

Just kidding of course. But if there would be a WOOF-CE commission, probably yes !

[wizard]

@wiak

fredx181 wrote: Sat Jan 25, 2025 7:09 am

I tested thoroughly, IMO it's an improvement altogether, however I still think that most puppy users are fine with the default pupsave-backup (oh.. those nerds ).
(so if this would make it through the WOOF-CE commission ... )

I'm confused with threads to do with Pupsave restore all seem to be happening at same time. What is difference to this other stuff by wizard here: viewtopic.php?p=141157#p141157

@fredx181 post just deals with Pupsave Backup, it's workings and dialogs. Pupsave-restore (the link you reference) actually performs the restore operation (extracting and renaming) so the user can choose the restored backup on reboot.

wizard

[peebee]

https://github.com/puppylinux-woof-CE/w ... 0ecea21811

[wizard]

@fredx181
@Governor

backup-fredx.png (31.86 KiB) Viewed 549 times

While this is an improvement, imagine you are a new or casual user trying to navigate this instruction.
Would be much easier to just have a program that can restore the backup for the user, could be referenced in above dialog.

Alternately, you could leave Pupsave Backup as is and include a restore program then have a menu entry that would call either backup or restore.

backup-restore.jpg (8.07 KiB) Viewed 549 times

Here's a mod of Pupsave-restore with that frontend: viewtopic.php?t=13697

wizard

Just more ideas.

wizard

[Governor]

@fredx181
@Governor
backup-fredx.png

While this is an improvement, imagine you are a new or casual user trying to navigate this instruction.
Would be much easier to just have a program that can restore the backup for the user, could be referenced in above dialog.

IMO:
All the information in fredx181's dialog box is important to know.
I really like having the information, it is easy enough to understand, and generally speaking, new users to Linux are seldom people completely new to computers.

Alternately, you could leave Pupsave Backup as is and include a restore program then have a menu entry that would call either backup or restore.
backup-restore.jpg

Here's a mod of Pupsave-restore with that frontend: viewtopic.php?t=13697

Just more ideas.

wizard

The menu provided by @wizard is great, and has a pleasant look, and ought to lead to the important information in the next step.

[wizard]

@governor

I really like having the information,

We all need to set our personal preferences aside and focus on who we're trying to help. That info is of little help to new and casual users.

it is easy enough to understand, and generally speaking, new users to Linux are seldom people completely new to computers

.
Would disagree here. Easy for you maybe, but even though they may not be new to computers, lots of them are new to Linux in general and Puppy in particular. They know nothing about Puppy's file structure or where to find /mnt/home or even what tool to use to navigate there and how to "extract" a file, rename it and put it in the right place.

wizard