I'll clarify my previous post.
Below are the two errors cited by the OP:
Governor wrote: Sat Jan 18, 2025 12:06 pm
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
geo_c wrote: Sat Jan 18, 2025 4:32 pm
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:
Governor wrote: Sun Jan 19, 2025 8:17 am
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........ ![Laughing :lol:](./images/smilies/icon_lol.gif)