Mistakes in GUI backup, please fix (Pupsave Backup)

[geo_c]

Not to throw a wrench in the works, but there were two issues the OP discusses. The other one was the naming convention. In other words, the pupsave-backup user must be informed that the prefix before the dash in the name of the backup connot be altered, and that this will prevent puppy from loading it at boot, or even displaying it as a boot choice.

I think this GUI is going to require a more thorough explanation to cover all these contingencies. For one, only puppy versions that can load timestamped backups with the BKP delimiter can boot it. Others can't unless the BKP delimiter is removed, so the text would have to be tailored for individual pups. Of course Bookworm doesn't have this issue. Perhaps no new pups would have that issue, but I don't know because I don't how all the developers configure their builds.

The GUI might have to say something along the lines of:

You now have a choice whether to the compress the backup. For future bootup purposes, a backup file/folder can be loaded at boot if located in the search path of the bootloader. However, choosing to compress now would first require uncompressing before attempting to load at boot,. NOTE: For some puppy versions, particularly older ones, the BKP delimiter must be removed from the name of the backup save in order to be seen by the boot sequence, and the prefix before the dash of the file/folder name must remain consistent and read [USE APPROPRIATE CODE TO DETERMINE THE SAVE NAME]

[geo_c]

I'll clarify my previous post.
Below are the two errors cited by the OP:

In the GUI backup procedure, there are two serious mistakes:
It is a serious mistake in the GUI to NOT inform the user that a compressed backup cannot be booted from.
It is an error, which causes users to reject Puppy. Developers need to take this type of error seriously.
..
The second serious mistake is while the user can name the backup file whatever they like, there is no mention that the backup file must conform to a specific naming convention,
where the first part of the name (including the hyphen), must not be changed, ie. dpupbw64save-BKP.2024.06.21-13.42

As seen below, I was mistaken when I suggested that the intent of the pupsave-backup script is not to create a bootable file, and the fact that it is bootable is more or less a benefit of the flexible nature of the puppy persistance structure (added benefit) mea culpa

When a filesystem is zipped it can be named anything the user wants, so the savefile naming procedure would be something only applicable to bootable saves and addressed in the intitial [first shutdown] save routine, which it is (as I have demonstrated,) and it would be confusing to state that the zipped backup must use a certain naming convention that is in fact not at all a requirement for a zipped backup.

Below the OP definitively proved that my assumption was quite wrong:

WRONG!!

1) A zipped backup doesn't require any sort of naming convention, because it's zipped and it can't be booted into it (because it's zipped). When it is unzipped it requires the same naming convention that the original folder or file required. There is nothing suggesting otherwise in these gui's.

The GUI interface is the communication between the OS and the user. This case has nothing to to with zipped files which are not even mentioned.

I admit I found the logic of the above statement, "This case has nothing to do with zipped files which are not even mentioned," hard to grasp, as I was under the impression from the first post that not being able to boot into a compressed pupsave-backup was part of the error the developers made when not mentioning that fact. I'm still giving it some thought. Perhaps the OP was saying that the GUI never used the phrase "zipped file". It was probably poor word choice on my part, and I should have consistently used the word "compressed". again mea culpa

Nevertheless, since pupsave-backup is now considered a tool for creating a bootable backup, it stands to reason that all the bases should be covered.

Hence my suggested new text in the previous post,. It's a little longer, yes. But does it even go far enough?

Considering all of the factors, the OP has a point that the user should not be given the option to change the first part of the file name, so it seems appropriate to rewrite that section of code to prevent the user becoming disillusioned in the event the developers again make a mistake by failing to adequately explain the possible future uses and manipulations of the pupsave-backup.

I can't help but get the sense that the suggeston of the added text "A compressed backup cannot be booted into" falls painfully short of the kind of user-friendliness we're capable of here.

But of course we are missing the obvious, if there is a backup routine, then it follows that a true user friendly system would also provide a restore routine. That script seems easy enough to write, just have it uncompress the file (or not if it's not compressed) and rename the folder or file appropriately.. but since I only figured out about a year or two ago that if you type ./ before an executable in the terminal, the executable will run, I'm probably not the guy to write the code.

I'm sure someone will come along........

[bigpup]

Now this is the old Puppy way.

Everyone working on a fix and bouncing ideas off each other!

This is how most of the Puppy specific programs got produced, including Pupsave Backup.

[bigpup]

Now that you can just use a backup save as it is named.

Restore is not needed as a function of Pupsave Backup.

You just stop using the old or broken save and use the good backup one.

If both saves are located where they can be found at boot up.
The choice is now given during boot up which one to use.

Now the choice is replace not restore.

Keep in mind the changes this topic is suggesting is for how Puppy works now and what Pupsave Backup now needs to provide.

Older Puppies are not going to have the exact same version of Pupsave Backup.

[bigpup]

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

You do need to first register and get a password.
Best to use the same name you use on this forum.
That name will most likely be recognized.

On the pull request page click on New pull request.

Basically it is written just like making a post on this forum.

A problem or issue with something that is provided by Woof-CE and this is my fix for it.

Do need to be willing to discuss what you offer, suggestions to change, add to, etc......

Read a few pull requests and you can see them as examples.

At the top of the list of submitted pull requests. It has open and closed.

open shows ones submitted but not acted on yet.

Closed when clicked on will give list of the ones that have been acted on.

[williwaw]

if there is a backup routine, then it follows that a true user friendly system would also provide a restore routine. That script seems easy enough to write, just have it uncompress the file (or not if it's not compressed) and rename the folder or file appropriately..

If each backup is compressed by default at creation and the gui incorporated radio buttons next to the displayed backups.

then the action to restore would be to

copy the selected compressed backup to a .gz with a new name and uncompress the copy, thus making it a viable choice at next boot.
compressing the backup at creation would prevent it from becoming inadvertently corrupted should it be booted into before it was chosen as a restore point

[Governor]

@Governor Your version says what it can not do, but what to do then ? Please explain !

How would you add this on a new line; would it take line 150 and push all subsequent lines up one? I am guessing the " would end the 2nd line of text.

Easiest to figure out for you and to explain for me: have look at the attachment (lines 150 151) from me (pupsave-backup): https://www.forum.puppylinux.com/viewto ... 97#p140797

I saw the file you attached. It is just as I thought it would be.

Your version is fine by me, except it does not tell the user that an uncompressed backup is bootable. There are plenty of systems where a backup file is not bootable. When I discovered the backup file was bootable, it was a total (but pleasant) surprise. It is important information, and only natural, that the user ought be told this up front.
Maybe this?
Note: Compressed pupsave backups must be decompressed to be bootable

The font size in the dialog box is very small which makes it hard to read. How difficult is it to increase the font size from 10 to 12? If there is a universal default font size for text in these dialog boxes, can the default be made 12 instead of 10? Even if the default font is adjustable by the user, it would, IMO, be beneficial for the default font to be set at 12 to start with. I could be wrong, but as far as I can see, there ought not be a problem with increasing the default dialog text font by 2 points.

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 is it to take a cancel button routine and stick it in the appropriate place so there is [Cancel] [No] [Yes]?

[Governor]

"Compressed backups must be decompressed before use"

wizard

Your version is fine by me, except it does not tell the user that an uncompressed backup is bootable. There are plenty of systems where a backup file is not bootable. When I discovered the backup file was bootable, it was a total (but pleasant) surprise. It is important information, and only natural, that the user ought be told this up front, IMO..

[Governor]

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

You do need to first register and get a password.
Best to use the same name you use on this forum.
That name will most likely be recognized.

On the pull request page click on New pull request.

Basically it is written just like making a post on this forum.

A problem or issue with something that is provided by Woof-CE and this is my fix for it.

Do need to be willing to discuss what you offer, suggestions to change, add to, etc......

Read a few pull requests and you can see them as examples.

At the top of the list of submitted pull requests. It has open and closed.

open shows ones submitted but not acted on yet.

Closed when clicked on will give list of the ones that have been acted on.

This is great info, thanks. I am thinking about it.

[fredx181]

"Compressed backups must be decompressed before use"

wizard

Your version is fine by me, except it does not tell the user that an uncompressed backup is bootable. There are plenty of systems where a backup file is not bootable. When I discovered the backup file was bootable, it was a total (but pleasant) surprise. It is important information, and only natural, that the user ought be told this up front, IMO..

Why a surprise ? What else should be a backup for then to be able to use it ?
Btw, the term 'bootable' or 'boot from' isn't right for a pupsave IMO (e.g. 'usable' or 'boot with' would be better) . Booting is done in the first place from the initrd and the .sfs files.

[fredx181]

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

You do need to first register and get a password.
Best to use the same name you use on this forum.
That name will most likely be recognized.

On the pull request page click on New pull request.

Basically it is written just like making a post on this forum.
....
....

I thought you need also to fork woof-CE first. Not ?

[Governor]

"Compressed backups must be decompressed before use"

wizard

Your version is fine by me, except it does not tell the user that an uncompressed backup is bootable. There are plenty of systems where a backup file is not bootable. When I discovered the backup file was bootable, it was a total (but pleasant) surprise. It is important information, and only natural, that the user ought be told this up front, IMO..

Why a surprise ? What else should be a backup for then to be able to use it ?
Btw, the term 'bootable' or 'boot from' isn't right for a pupsave IMO (e.g. 'usable' would be better) . Booting is done in the first place from the initrd and the .sfs files.

Ok, you mean the terms 'bootable' or 'boot from' are technically inaccurate because my OS is already alive or engaged when I choose an item from my bootmenu.
I am at a loss as how to clarify it to newbies, because they would only consider a computer to be successfully 'booted' when they see the GUI loaded. Is there no better way to explain it? Usable to me means little, without indication of how the backup can be used. when I see usable, I think, usable how? Will it be available to use as a menu choice on the next boot? Will I need to run a restore program and replace my current OS, and then reboot? Will I need to copy the pupsave to a particular folder?

Also, when should the user be informed about the file naming requirements, ie. in a pupsave such as this, "dpupbw64save-BKP.2024.06.21-13.42" the first part of the filename must not be changed, or it will not be recognized as a puppy backup file. The user needs to be warned at some point when they create the backup, not to change the first part of the filename.

How about something like:
usable on your next boot
OR
a usable choice in your bootmenu

[geo_c]

Also, when should the user be informed about the file naming requirements, ie. in a pupsave such as this, "dpupbw64save-BKP.2024.06.21-13.42" the first part of the filename must not be changed, or it will not be recognized as a puppy backup file. The user needs to be warned at some point when they create the backup, not to change the first part of the filename.

How about something like:
usable on your next boot
OR
a usable choice in your bootmenu

This is why an actual small paragraph is necessary:

You now have a choice whether to the compress the backup. For future bootup purposes, a backup file/folder can be loaded at boot if located in the search path of the bootloader. However, choosing to compress now would first require uncompressing before attempting to load at boot,. NOTE: In order to be seen by the boot sequence, the prefix and the dash of the file/folder name must remain consistent and read dpupbw64save-[ANY ADDITIONAL PERSONALIZED ALPHA NUMERIC CHARACTERS]

[Governor]

Also, when should the user be informed about the file naming requirements, ie. in a pupsave such as this, "dpupbw64save-BKP.2024.06.21-13.42" the first part of the filename must not be changed, or it will not be recognized as a puppy backup file. The user needs to be warned at some point when they create the backup, not to change the first part of the filename.

How about something like:
usable on your next boot
OR
a usable choice in your bootmenu

This is why an actual small paragraph is necessary:

You now have a choice whether to the compress the backup. For future bootup purposes, a backup file/folder can be loaded at boot if located in the search path of the bootloader. However, choosing to compress now would first require uncompressing before attempting to load at boot,. NOTE: For some puppy versions, particularly older ones, the BKP delimiter must be removed from the name of the backup save in order to be seen by the boot sequence, and the prefix before the dash of the file/folder name must remain consistent and read [USE APPROPRIATE CODE TO DETERMINE THE SAVE NAME]

Good point, brief is not always best. Correct me if I am wrong, but it is up to and including the dash that is needed to be recognized as a backup file, right?
However, in this case the documentation is only needed for the current version. It is not feasible to give instructions or clarification for for past versions, and it would be confusing for users. Going forward, future versions will (little by little) include clearer documentation which will eventually mean more satisfied users.

[geo_c]

Good point, brief is not always best. Correct me if I am wrong, but it is up to and including the dash that is needed to be recognized as a backup file, right?
However, in this case the documentation is only needed for the current version. It is not feasible to give instructions or clarification for for past versions, and it would be confusing for users. going forward, future versions will include better documentation which will eventually mean more satisfied users.

Yes I edited the text in the above post to this:

You now have a choice whether to the compress the backup. For future bootup purposes, a backup file/folder can be loaded at boot if located in the search path of the bootloader. However, choosing to compress now would first require uncompressing before attempting to load at boot,. NOTE: In order to be seen by the boot sequence, the prefix and the dash of the file/folder name must remain consistent and read dpupbw64save-[ANY_PERSONALIZED_ALPHA_NUMERIC_CHARACTERS]

[fredx181]

Another thing (just tested, admittedly it's first time I tried with the 'compressed' option):
When chosen for a compressed backup, then if you uncompress it later with e.g. Uextract, then it results in a folder named e.g.:
dpupbw64save.BKP-2025.01.21-14.20.tar.gz.extracted
Inside is the save backup, it's named just dpupbw64save (same as the standard name).
Required then is to rename it differently, e.g. dpupbw64save-1 and cut/paste to the same level as the original dpupbw64save.

[rockedge]

@fredx181 Perhaps that step can be automated in a script.....

[geo_c]

Another thing (just tested, admittedly it's first time I tried with the 'compressed' option):
When chosen for a compressed backup, then if you uncompress it later with e.g. Uextract, then it results in a folder named e.g.:
dpupbw64save.BKP-2025.01.21-14.20.tar.gz.extracted
Inside is the save backup, it's named just dpupbw64save (same as the standard name).
Required then is to rename it differently, e.g. dpupbw64save-1 and cut/paste to the same level as the original dpupbw64save.

Well all the various extract tools will be different.

For instance, when I extract using Xfe right click, it gives the option of extracting contents to a folder with the name of the compressed file (without the tar.gz extension), or simply extracting the contents to the present working directory. If I choose the former then I have to move the folder out of the Xfe created folder. And of course as you pointed out, the compressed folder does not contain the timestamp and BKP identifier.

edit: And it seems to me that maybe the script should rename the folder using the compressed backup filename information, and then it will be a choice at boot, as opposed to naming it the same as the original save, which correct me if I'm wrong, would then overwrite the original. which in that case would be acting like a restore function.

[fredx181]

the compressed folder does not contain the timestamp and BKP identifier

Yes, if it does, it'd be a whole lot better.
For example, serious trouble (unexpected) can occur, I tested uncompressing with Xarchiver by "Extract Here" (from Thunar) and the files in dpupbw64save got overwritten by the files from the backup.
edit: I see now you wrote similar at "edit"

[Governor]

the compressed folder does not contain the timestamp and BKP identifier

Yes, if it does, it'd be a whole lot better.
For example, serious trouble (unexpected) can occur, I tested uncompressing with Xarchiver by "Extract Here" (from Thunar) and the files in dpupbw64save got overwritten by the files from the backup.

My guess is that the compress option stems from a time when storage was limited. If there are various complications using this feature, I would vote for removing the compress feature from the pupsave backup altogether. Once people have created backups, they are free to compress as desired. It just doesn't seem like a necessary feature at this point in time.

The naming restrictions are real and IMO, need to be mentioned to the users in an appropriate place so that users know not to change the first part of the file name up to and including the hyphen, and for the record, I believe it is a hyphen and not a dash, (I am pretty sure dashes are longer).

[williwaw]

which in that case would be acting like a restore function.

but doesnt pupsave backup need a restore function, and is this not how you can implement it?

[geo_c]

which in that case would be acting like a restore function.

but doesnt pupsave backup need a restore function, and is this not how you can implement it?

I don't think it is that simple. As @fredx181 pointed out, if you make the backup in dpupbw and then overwrite the original save while running....

well, that would be very offputting to new users, crashing the whole sytem beyond repair I mean.

edit: of course @fredx181 has an excellent backup and restore script for KL's, so if anyone can do it, it's him.

[geo_c]

My guess is that the compress option likely stems from a time when storage was limited. If there are various complications using this feature, I would vote for removing the compress feature from the pupsave backup altogether. Once people have created backups, they are free to compress as desired. It just doesn't seem like a necessary feature at this point in time.

Well, that was something I mulled over myself. I never used the compression feature until a doy or two ago to test it.

But it's always a question of who is using it. I'm sure there are some people who compress all their backups, because they are actually using the script for it's original purpose, that is backing up, and not as alternate bootable save creation.

So they would be of course not happy with having to compress after the fact, I imagine.

They are similar uses, but not identical.

[williwaw]

which in that case would be acting like a restore function.

but doesnt pupsave backup need a restore function, and is this not how you can implement it?

overwrite the original save while running....

well, that would be very offputting to new users, crashing the whole sytem beyond repair I mean.

I just did it in vanilladpup without a problem, not in bookworm tho.
but if one was running in a mode that was writing to save at the time the uncompressing happened.... I see your point

[geo_c]

but doesnt pupsave backup need a restore function, and is this not how you can implement it?

overwrite the original save while running....

well, that would be very offputting to new users, crashing the whole sytem beyond repair I mean.

I just did it in vanilladpup without a problem, not in bookworm tho.
but if one was running in a mode that was writing to save at the time the uncompressing happened.... I see your point

That must be because your doing save on demand rather than direct-write. In that case yes, you could over-write your current save stored on disk that's currently loaded in ram, BUT, I think if you did anything else significant while running in ram, then saved over the old backup you just restored, you might get conflicts and issues on your next boot.

[williwaw]

yes, if your present corrupted session wrote to ram after you uncompressed then the corruption you are trying to restore from would be perpetuated.

maybe the command to uncompress/restore should actually happen after any saves at shutdown or perhaps at the next boot.

[geo_c]

yes, if your present corrupted session wrote to ram after you uncompressed then the corruption you are trying to restore from would be perpetuated.

maybe the command to uncompress/restore should actually happen after any saves at shutdown or perhaps at the next boot.

Well, the idea is to save it under a distinct name from the currently loaded save. Then reboot, getting it as a choice. This is what the OP wants, but simply wants to be informed on how to do it properly.

If it's a pure restore, in other words rolling back the current save to a backup and retiring the current, then the current save would need to be renamed, but you can't do that in direct-write mode, (pupsave something, I can never remember.)

Or there could be a numbering scheme imposed on by the pupsave-backup routine, blah blah, it gets murky.

There lies the complexity.

You either take away flexibility and change it into a rollback script, or leave options, and that's where the user has to understand how the save process works, and how their logic fits into their use case.

[fredx181]

the compressed folder does not contain the timestamp and BKP identifier

Here's modified /usr/sbin/pupsave-backup.
when create compressed backup of savefolder it will be with BKP.<timestamp> added to the name inside the archive (instead of the original name of the savefolder you booted with)
See changes at lines from 199 to 222 .

pupsave-backup.gz

To test: Remove fake .gz, make executable and replace in /usr/sbin/

(12.3 KiB) Downloaded 8 times

[williwaw]

You either take away flexibility and change it into a rollback script, or leave options,

why either or? I think it is a shame to work on the app without adding a restore feature, but I admit the scenarios thus far proposed havent quite worked out the logic correctly yet. Lets wait for the OP to see what he wants to do.

[fredx181]

You either take away flexibility and change it into a rollback script, or leave options,

why either or? I think it is a shame to work on the app without adding a restore feature, but I admit the scenarios thus far proposed havent quite worked out the logic correctly yet. Lets wait for the OP to see what he wants to do.

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))