Hot Backup for Frugal Pups Updated 2011-10-1
I found something interesting in your Pupsave-backup file.
I know it works as is, but the line "<label>"<span color='blue'>Pupsave file to backup</span>"</label>" according to another script on span is wrong.
It should be "<label>"<span color= '"'blue'"'> for that part of the span code.
That is color= single quote, double quote,single quote,color,single quote, double quote, single quote.
At least, when I tried that line in a short script, it kicked out a gtk error.
Maybe I am missing something in looking at the code.
Also, I get the same file named 0 when I run the Pupsave-backup script.
Could it be a matter of a variable not being populated that is the path/filename of one of the temp files?
I know it works as is, but the line "<label>"<span color='blue'>Pupsave file to backup</span>"</label>" according to another script on span is wrong.
It should be "<label>"<span color= '"'blue'"'> for that part of the span code.
That is color= single quote, double quote,single quote,color,single quote, double quote, single quote.
At least, when I tried that line in a short script, it kicked out a gtk error.
Maybe I am missing something in looking at the code.
Also, I get the same file named 0 when I run the Pupsave-backup script.
Could it be a matter of a variable not being populated that is the path/filename of one of the temp files?
Last edited by 8-bit on Wed 28 Sep 2011, 00:48, edited 1 time in total.
Hello 2byte
I installed your new .pet but I am now having a different set of problems. It opens extremely slowly. When setting the path to where the backup is to be stored each page again is very slow to open. This was not the case with the original script. I decided at this point something must be wrong and did not try to make a backup. It also installed a file named "0" in/my-applications/bin (see attached).
I found a version of this file after deleting the previous script but at that time did not know where it had come from. I had trouble deleting this file. Should this file be created? I have come to the conclusion that this is not going to work with my set up although I still don't know why. I think I will have to go back to manual backups.
Thanks again for trying to get it to work with my setup.
Regards,
Ken.
I installed your new .pet but I am now having a different set of problems. It opens extremely slowly. When setting the path to where the backup is to be stored each page again is very slow to open. This was not the case with the original script. I decided at this point something must be wrong and did not try to make a backup. It also installed a file named "0" in/my-applications/bin (see attached).
I found a version of this file after deleting the previous script but at that time did not know where it had come from. I had trouble deleting this file. Should this file be created? I have come to the conclusion that this is not going to work with my set up although I still don't know why. I think I will have to go back to manual backups.
Thanks again for trying to get it to work with my setup.
Regards,
Ken.
- Attachments
-
- bin.png
- (28.27 KiB) Downloaded 896 times
Hi keniv
I want to thank you for spending your time on this. It has been extremely helpful to me for getting bash 4 compatibility.
I never noticed the 0 file until you mentioned it. It seems that bash 4 doesn't like 'if' comparisons that have a > as part of the equation. At least not the way I had constructed them in bash 3. That caused the latest problem with the 0 file. It was being recreated every 0.2 seconds. No wonder it was hard to delete while the gui was running. Ditto for the slow operation, which was not noticeable on my rig. This is fixed now but I think I'll wait before uploading it.
With this bash 4 business it seems to me like every time one bug is fixed, two more are created.
Once again, thanks Ken
Regards,
2byte
I want to thank you for spending your time on this. It has been extremely helpful to me for getting bash 4 compatibility.
I never noticed the 0 file until you mentioned it. It seems that bash 4 doesn't like 'if' comparisons that have a > as part of the equation. At least not the way I had constructed them in bash 3. That caused the latest problem with the 0 file. It was being recreated every 0.2 seconds. No wonder it was hard to delete while the gui was running. Ditto for the slow operation, which was not noticeable on my rig. This is fixed now but I think I'll wait before uploading it.
With this bash 4 business it seems to me like every time one bug is fixed, two more are created.
Once again, thanks Ken
Regards,
2byte

added software to wiki under name PupsaveBackup
http://puppylinux.org/wikka/PupSaveBackup
http://puppylinux.org/wikka/PupSaveBackup
Hello 2byte
Thanks for your reply and explanation of what was going on. I am glad that it may not be a peculiarity of my system that has been causing the problems I have been having. When you are ready to upload again I will have another go at getting it to work on my system. I still think its a great idea.
Regards,
Ken.
Thanks for your reply and explanation of what was going on. I am glad that it may not be a peculiarity of my system that has been causing the problems I have been having. When you are ready to upload again I will have another go at getting it to work on my system. I still think its a great idea.
Regards,
Ken.
Well done 2byte.
Today it's the first time that I've tested your program, and it works fine.
Till now I've just copied my save file in use, took care that no other prog was running, and it worked flawlessly since years. But with your script it works much more comfortably.
It works also on reiserfs formatted partitions.
For myself I like to be able to mount my save files without renaming them. So I will try to change your code, that the save file is named e.g.
lupusave-compileBKP-11.10.03-10.25.3fs.
Then maybe to get it working with my reiserfs formatted save files (.rfs).
Well, I'll see.
Thank you for this.
Rolf
Today it's the first time that I've tested your program, and it works fine.
Till now I've just copied my save file in use, took care that no other prog was running, and it worked flawlessly since years. But with your script it works much more comfortably.
It works also on reiserfs formatted partitions.
For myself I like to be able to mount my save files without renaming them. So I will try to change your code, that the save file is named e.g.
lupusave-compileBKP-11.10.03-10.25.3fs.
Then maybe to get it working with my reiserfs formatted save files (.rfs).
Well, I'll see.
Thank you for this.
Rolf
Last edited by rhadon on Mon 03 Oct 2011, 18:33, edited 1 time in total.
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
8-bit, and rhadon, thanks for the feedback. I can breathe a little easier now.
I think that just might be in the next update. Maybe not. Backward compatibility is important to me so it will take some time to test. Backup utilities seem to be springing up right and left
2byte
You know, you are the fourth person in the last week to mention leaving the file extension intact. Way back when I first wrote this I think I did leave the extension on, but the backup ended up being listed as a mountable pupsave at boot or Puppy would mount the first one it happened to find. At least that’s what I seem to recall but my memory is kind of cloudy nowadays. Anyway now that I think about it, the newer Woof Puppies look for a specific beginning of the pupsave name. So inserting the backup tag before the extension should still work for newer pups.For myself I like to be able to mount my save files without renaming them. So I will try to change your code, that the save file is named e.g.
lupusave-compileBKP-11.10.03-10.25.3fs.
I think that just might be in the next update. Maybe not. Backward compatibility is important to me so it will take some time to test. Backup utilities seem to be springing up right and left
2byte

Thank's 8-bit,
I've overseen this thread.
But anyway, it's too late, I got it working in Hot Backup.
Building such a script is far beyond my skill, but finding out how a given script works or changing a little bit, that's my way of learning.
In phb_core I replaced in function PHB_Bkpfilename() ~line #83
with
And something similar in function PHB_Backup().
Maybe it's not the best way but it seems to work.
Result for lupusave-compile.3fs:
lupusave-compile.BKP111003-17.58.3fs
Tested in Lupu-525 and 528.
@ 2byte
No matter what you are doing, some people will love it and some are moaning.
Different people, different needs and different expectations.
I don't know what's the best for most.
I'm just trying to learn a little bit. For now I'm lost in trying to understand how the validation of the save file works. It's e.g. completely different to the way, the init script validates.
But anyway, thank you
Rolf
I've overseen this thread.
But anyway, it's too late, I got it working in Hot Backup.
Building such a script is far beyond my skill, but finding out how a given script works or changing a little bit, that's my way of learning.
In phb_core I replaced in function PHB_Bkpfilename() ~line #83
Code: Select all
a="`expr "${1}" | awk -F / '{print $NF}'`".BKP-`date +%y.%m.%d-%H.%M`
Code: Select all
file="`expr "${1}" | awk -F / '{print $NF}'`"
num=$[${#file}-4]
ext=${file:$num}
name=${file:0:$num}
a=$name".BKP`date +%y%m%d-%H.%M`"$ext
Maybe it's not the best way but it seems to work.
Result for lupusave-compile.3fs:
lupusave-compile.BKP111003-17.58.3fs
Tested in Lupu-525 and 528.
@ 2byte
No matter what you are doing, some people will love it and some are moaning.
Different people, different needs and different expectations.
I don't know what's the best for most.
I'm just trying to learn a little bit. For now I'm lost in trying to understand how the validation of the save file works. It's e.g. completely different to the way, the init script validates.
But anyway, thank you
Rolf
Last edited by rhadon on Mon 03 Oct 2011, 18:55, edited 1 time in total.
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
2byte,
If you change the pupsave backup file format I will have to do a rewrite of my PupsaveRestore.sh as it expects to find the backup file name in the format you now have.
Also, getting it to work with both types of a backup file as to the name format would take further work.
I already have the code to remove the date-time from the filename of a backup with the format being "pupsave.BAK-11.10.03-10.30.sfs".
But it would take some additional checks to see which format the backup name was.
Anyway, I always figured "If it ain't broke, don't fix it."
I already know that if you try to mount the pupsave file of the same name as the one you have in use, it will not work.
But a dated backup pupsave with the extension at the end allows the user to mount it, maybe for the purpose of retrieving a file from it.
So there are some advantages I guess.
If you change the pupsave backup file format I will have to do a rewrite of my PupsaveRestore.sh as it expects to find the backup file name in the format you now have.
Also, getting it to work with both types of a backup file as to the name format would take further work.
I already have the code to remove the date-time from the filename of a backup with the format being "pupsave.BAK-11.10.03-10.30.sfs".
But it would take some additional checks to see which format the backup name was.
Anyway, I always figured "If it ain't broke, don't fix it."
I already know that if you try to mount the pupsave file of the same name as the one you have in use, it will not work.
But a dated backup pupsave with the extension at the end allows the user to mount it, maybe for the purpose of retrieving a file from it.
So there are some advantages I guess.
Jasper,
I have to agree with you as I had written a restore utility for hot backup files.
I also stated as part of restoring that one should boot with pfix=ram so as not to have any pupsave file loaded.
There is no magic solution to doing a restore of a pupsave to a puppy running with a pupsave file loaded.
I tried to do a hot restore and I do not even want to talk about the results.
So either boot to another version of puppy or boot with pfix=ram to delete the pupsave you are replacing with a backup.
The other way would be to copy the backup over with a different name and on reboot, you will be given the option of which pupsave file to load.
Load the backup you copied and delete the original if you do not want it.
You actually can have as many pupsave files as you want in a frugal install directory and choose between them when you boot.
I have to agree with you as I had written a restore utility for hot backup files.
I also stated as part of restoring that one should boot with pfix=ram so as not to have any pupsave file loaded.
There is no magic solution to doing a restore of a pupsave to a puppy running with a pupsave file loaded.
I tried to do a hot restore and I do not even want to talk about the results.
So either boot to another version of puppy or boot with pfix=ram to delete the pupsave you are replacing with a backup.
The other way would be to copy the backup over with a different name and on reboot, you will be given the option of which pupsave file to load.
Load the backup you copied and delete the original if you do not want it.
You actually can have as many pupsave files as you want in a frugal install directory and choose between them when you boot.
1. See this post.
I normally use Lupu booted from a live CD, with a lupusave on an internal HDD, but with that lupusave treated as though it's on a Flash Drive.
So then the other changes are made so the session is NEVER auto-saved DURING THE SESSION...
And I'm asked "Save the session = Yes/No?" at shut-down/reboot, so I can choose to not save then also.
2. Hence, although the lupusave can be read to have things loaded into RAM...
It would NOT be written to during any replacement by a RESTORED lupusave.
3. Would any subsequent write-back need to be made to the very same file as that which was read?
Or could the write-back be made to a replacement copy.
I normally use Lupu booted from a live CD, with a lupusave on an internal HDD, but with that lupusave treated as though it's on a Flash Drive.
So then the other changes are made so the session is NEVER auto-saved DURING THE SESSION...
And I'm asked "Save the session = Yes/No?" at shut-down/reboot, so I can choose to not save then also.
2. Hence, although the lupusave can be read to have things loaded into RAM...
It would NOT be written to during any replacement by a RESTORED lupusave.
3. Would any subsequent write-back need to be made to the very same file as that which was read?
Or could the write-back be made to a replacement copy.
Hi 2byte et al,
If it is possible to make a working "hot" save file restore package for a frugal Puppy installation; then does this mean that a user can, as of now, safely delete and replace (or overwrite) the current live save file with an older backup copy?
My regards
PS I always do a "cold" restore (delete then copy and paste) using a different Puppy (others may reboot and choose an alternative save file), but if a "hot" restore is safe it would save me a few minutes (even without any new automated restore facility).
If it is possible to make a working "hot" save file restore package for a frugal Puppy installation; then does this mean that a user can, as of now, safely delete and replace (or overwrite) the current live save file with an older backup copy?
My regards
PS I always do a "cold" restore (delete then copy and paste) using a different Puppy (others may reboot and choose an alternative save file), but if a "hot" restore is safe it would save me a few minutes (even without any new automated restore facility).