Pupsave Restore Backups Version 6

[fredx181]

...
2. Bigger issue, the program code uses this to find the backups:

Code: Select all

ls *.BKP*

This normally returns only the files/directories containing ".BKP".

That doesn't work in BW64. In the image below, the first "ls" command shows all contents
of the directory. Next, you see that "ls *.BKP*" returns only "upper" and "work", so the program will
fail. Have no idea why this happens, perhaps @dimkr or one of our other experts can explain it.

Thanks
wizard

This may work (avoiding output of the contents: "upper" and "work"):

-d, --directory list directories themselves, not their contents

ls -d *.BKP*/
But it adds a slash at the output, don't know if that gives an unwanted side-effect.
Without the appending slash: ls -d *.BKP* it will show also any other file, e,g. *tar.gz or *tar.xz containing .BKP in the name , not sure if that's wanted in your setup .

[wizard]

@fredx181

Yeah, found several ways to fix it:

ls -d *.BKP* (like your suggestion)
or
ls | grep -F ".BKP"

ls -d *.BKP*/ Not a good choice since the program needs a list of all the .BKP files

Could also do it with "find"

Right now am using: ls | grep -F ".BKP"

Really curious why BW64 gives ls *.BKP* output as the contents of the directory (upper, work) and older Pups give the list of files/directories with the .BKP string.

Thanks
wizard

[williwaw]

other puppies might call ls from buysbox?
and bookwormpup might be (the output below is from vanilladpup)

Code: Select all

0 ~ $ ls --version
ls (GNU coreutils) 9.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.

[wizard]

@bigpup

Made changes:
1. Now works in BookwormPup64
2. If user tries to "restore" an un-compressed" savefolder, a copy is made.

This version for testing only.

Let me know what happens and if #2 is a good approach.

Thanks
wizard

[wizard]

@williwaw

other puppies might call ls from buysbox?

Not sure about that. BW64 also has ls version 9.1, wonder if you duplicated @bigpup test condition of choosing an un-compressed savefolder backup, would you get the same failure?

Thanks
wizard

[williwaw]

I have always gotten the output of work and upper with vanillaDpup, Makes sense to me as you are passing the foldername as an arguement to ls, albiet with wildcards. I also tried various iterations of wildards with and without the dot before BKP. will test your latest soon.

Have you been following the discussion in viewtopic.php?t=644

edit: download/file.php?id=28941 worked fin both compresses and uncompressesed with vanilladpup

[wizard]

See first post for Revision 250130
Version 4 now adds the date of the original backup to the restore name.

wizard

[wizard]

@williwaw

I have always gotten the output of work and upper with vanillaDpup, Makes sense to me as you are passing the foldername as an arguement to ls, albiet with wildcards.

The disturbing thing is older versions of "ls" do not produce that output. They changed the behavior of the "ls" command.

Thanks for testing, take a look at Version 4.

wizard

[fredx181]

Don't know if it's useful, but using echo rather than ls works too:
echo *.BKP* # should be without double quotes
Example output:
dpupbw64save-1.BKP-2025.01.26-11.15-RESTORED

[some1]

ls uses fileglobbing as input.
We dont need ls - which is a dubious tool.
*.BKP* is our glob
echo *.BKP* outputs 1 line i.e. file1 file2 .....
try:

Code: Select all

shopt -s nullglob

cd path/to/saves
for i in *.BKP*; do
echo $i
done >out.txt

out.txt will contain:
file1
file2
....
....
if needed - we can do tests for dirs,files,links inside the for loop.

Edit:
Added shopt -s nullglob
in case no BKP items a glob will produce the commandspecs i.e. *.BKP*
we dont want that - so by setting nullglob we just get an empty line in this case
shopt -s nullglob is also relevant with the ls and echo examples above

[MochiMoppel]

echo *.BKP* outputs 1 line i.e. file1 file2 .....
try:

Code: Select all

shopt -s nullglob
cd path/to/saves
for i in *.BKP*; do
echo $i
done >out.txt

.. or - if testing for dirs,links etc. is not required - avoid looping with

Code: Select all

shopt -s nullglob
cd path/to/saves
printf '%s\n' *.BKP* >out.txt

[some1]

Yes - printf is the best choice -if we just want the raw listing.
----
But we do have saveDIRS,saveFILES plus compressed items.
So perhaps a gui-listing should do some groupings -if needed.
The raw glob will produce a sorted listing.
----
I think Governor had some good points.
A backup/restore tool, which is sufficiently informative/failsafe to newcomers,
seem to me to be a worthy/important endevour.
Newcomers - whether from windows,Mac or Linux - are confronted with
a lot of puppy-peculiarities.The save/persistence-system is one of those.
To be able to easily make fuzz-free backups/milestones is important to the experience furtheron.

However - seasoned users -may have their own modus operandi - and personally
I dont think I would use a tool,which send me through a plethora of dialogs.
So perhaps a final tool - should come in two or more flavours -targeting
different needs for information/handholding.

But yes - I think its a good project - worth serious effort in coding and mapping
the universe.

[bigpup]

I hope you can all see this is Puppy Linux way of producing a program.

One person comes up with the idea for a needed program and bangs out some code they think will work.

Others test it and offer information on issues, how it worked for them, maybe suggestions, help to find fixes, etc..........

Being open to accepting help of any kind, is how Puppy Linux has always been.

Sure hope this way of making a good Puppy Linux program, will never change.

Testing v4 now.

sorry, but I do not like using the word restore or restored.
I know someone is going to take an old backup save, restore it.
Thinking they just produced a good save to use, that is going to have in it, everything the broken save had, that was added after making that old backup.
Nothing added to the working save, after the backup was made, is going to be in the backup.

But not sure what word would apply.

UN-compress/copy

So I guess we will have to be ready to explain, restoring a backup does not restore the broken save. It restores the backup save and makes a copy, that can be used to boot with.
Still retaining the original backup for safe keeping.
Providing a save with contents at the time of making the backup.

[bigpup]

@bigpup

Made changes:
1. Now works in BookwormPup64
2. If user tries to "restore" an un-compressed" savefolder, a copy is made.

This version for testing only.

Let me know what happens and if #2 is a good approach.

Thanks
wizard

BookwormPup64 10.0.9

Did a restore of a compressed backup save folder and a not compressed backup save folder.
It produced a copy of each one.

Seems to work OK now, no issues to report.

The compressed save did take a long time to make the restored not compressed copy, but it is a big backup, so that time is expected.

I do like restore making a copy of the backup save to use.
The good original backup save, is still available, if it still needs to be used to make another copy.
Can never have too many backups!

Now on boot up, I have 4 saves to choose from, to use.
Original working save.
UN-compressed backup save.
The two restored copies.

.

[williwaw]

But not sure what word would apply.

snapshot would be right since the bkp includes the timestamp

[some1]

Just some questions:
Perhaps a logfile is relevant monitoring the order of saves and restores?
Is it obvious to a user - which backup has been used for the actual state of
a puppy?
Ex:
If I restore backup xxxx
work for some time changing settings etc.
do some saves
can I see - after awhile - that the changes/subsequent saves was based on backup xxxx?

[greengeek]

Just some questions:
Perhaps a logfile is relevant monitoring the order of saves and restores?
Is it obvious to a user - which backup has been used for the actual state of
a puppy?
Ex:
If I restore backup xxxx
work for some time changing settings etc.
do some saves
can I see - after awhile - that the changes/subsequent saves was based on backup xxxx?

Yes, a logfile may be necessary.
Otherwise I see two ways:
1) Allow user to rename save eg: "xxxx-includePrinterSoftwareAndWordProc.."
or
2) Force the backup procedure to include a text file where the user can write what is important to them eg:
- Added Printer
- Added Word processor
- Added list of other software that worked well.
etc

ie: similar to the other efforts that have gone on to force puppy to handle packages the way Debian does it etc - in other words "real" package managers have lists of what "to do" or what "to undo" - complete with the complexity of what goes along with that sort of thing (apt/gslapt/pacman etc)

Has to be either "easy" and modifiable by simple users, or else "totally controlled" by the backup utility.

[bigpup]

If you boot using a backup save as the save that is being used.

That is now select-able to do on boot up.

As soon as you make any changes, it is no longer the same backup save.

It is now a different save with different stuff in it.

[some1]

As soon as you make any changes, it is no longer the same backup save.

It is now a different save with different stuff in it.

More strictly: The system,apps may make more or less subtle changes - which the user is not aware of - so we can not assume - that saving a loaded backup
produces a save identical to the backup loaded.

[wizard]

@fredx181

Don't know if it's useful, but using echo rather than ls works too:
echo *.BKP* # should be without double quotes

Had no idea echo could do that, every project get to learn something new.

Thanks
wizard

[williwaw]

If you boot using a backup save as the save that is being used.

That is now select-able to do on boot up.

As soon as you make any changes, it is no longer the same backup save.

It is now a different save with different stuff in it.

which is why pupsave backup should compress all backups

[geo_c]

If you boot using a backup save as the save that is being used.

That is now select-able to do on boot up.

As soon as you make any changes, it is no longer the same backup save.

It is now a different save with different stuff in it.

which is why pupsave backup should compress all backups

Or, because many of us use pupsave-backup to create an alternate working save for loading at boot, the pupsave gui text could indicate something like:

You now have a choice to create either a compressed backup file for archiving, or an uncompressed alternate folder/file for loading at boot.
[compressed archive button] [alternate save button] [cancel button]

[rcrsn51]

Or, because many of us use pupsave-backup to create an alternate working save for loading at boot,...

Maybe the solution is to have two apps.
1. A proper backup/restore app, which is what most users need.
2. A much simpler "Pupsave Duplicate" app which just makes a copy of the current pupsave under a different name in the same location.

[Wiz57]

Or, because many of us use pupsave-backup to create an alternate working save for loading at boot,...

Maybe the solution is to have two apps.
1. A proper backup/restore app, which is what most users need.
2. A much simpler "Pupsave Copy" app which just makes a copy of the current pupsave under a different name in the same location.

OR...people should LEARN how to use a file manager (Rox, Thunar, Dolphin, PCManFM, etc) and simply right click on their savefile/folder
then choose "Copy", or press CTRL+C, etc, then choose a new location on their storage media and right click, then paste... or quicker
CTRL+V to paste! But then again, whenever something idiot proof is designed, the world creates a new and improved idiot!

[fredx181]

Or, because many of us use pupsave-backup to create an alternate working save for loading at boot,...

Maybe the solution is to have two apps.
1. A proper backup/restore app, which is what most users need.
2. A much simpler "Pupsave Copy" app which just makes a copy of the current pupsave under a different name in the same location.

OR...people should LEARN how to use a file manager (Rox, Thunar, Dolphin, PCManFM, etc) and simply right click on their savefile/folder
then choose "Copy", or press CTRL+C, etc, then choose a new location on their storage media and right click, then paste... or quicker
CTRL+V to paste! But then again, whenever something idiot proof is designed, the world creates a new and improved idiot!

I'd not recommend using a file manager to copy a save folder as it may choke on certain files , e.g. whiteout files (.wh for when aufs used) or (when used overlayfs) 'character' device files.
Better use cp or rsync for that.

[williwaw]

I'd not recommend using a file manager to copy a save folder as it may choke on certain files , e.g. whiteout files (.wh for when aufs used) or (when used overlayfs) 'character' device files.
Better use cp or rsync for that.

if "copy" or "duplicate" as seen in the right click text menu does not use cp, then what does it use?

[fredx181]

I'd not recommend using a file manager to copy a save folder as it may choke on certain files , e.g. whiteout files (.wh for when aufs used) or (when used overlayfs) 'character' device files.
Better use cp or rsync for that.

if "copy" or "duplicate" as seen in the right click text menu does not use cp, then what does it use?

Don't know, it's' "own" I guess, all I know that I've experienced problems, specially with Thunar and PCmanFM, (perhaps with Rox it's ok, not sure though), although it does give a clear message that it cannot copy some 'special' files and prompt for skipping it, so that's ok on itself, but not what we want when copying a save folder of course.

[wizard]

@fredx181

Don't know, it's' "own" I guess, all I know that I've experienced problems, specially with Thunar and PCmanFM, (perhaps with Rox it's ok, not sure though), although it does give a clear message that it cannot copy some 'special' files and prompt for skipping it, so that's ok on itself, but not what we want when copying a save folder of course.

Have seen the copy savefolder issue with Rox vs XFE. XFE chokes on some files and ROX does not.

Thanks
wizard

[mikewalsh]

@fredx181 :-

How about the old standby, "dd"? I know it works at a very low level, and that it is LITERALLY 'byte-for-byte'.....including unused bytes, and blank bytes, etc, etc.....but it DOES always work (so long as you're very careful to get the "magic formula" just right, of course)!

Just a thought, like....

Mike.

[fredx181]

@fredx181 :-

How about the old standby, "dd"? I know it works at a very low level, and that it is LITERALLY 'byte-for-byte'.....including unused bytes, and blank bytes, etc, etc.....but it DOES always work (so long as you're very careful to get the "magic formula" just right, of course)!

Mike.

Question for me? You gotta learn something Mike : There are many things that you cannot ask me about !
But, perhaps anyone have opinion about using dd ?