Page 2 of 2

Posted: Thu 15 Aug 2013, 22:57
by mikeb
Have fun. The other 99.99% of us will continue to use savefiles while you save to your sfs.
I will thanks since is solid and reliable and I don't have to think of ways of fixing it. Works on Slax too. Being in a minority does not necessarily mean suffering in some way :D

Thanks for the friendly banter

mike

ps I promise not to mention my save folder option......

Posted: Fri 16 Aug 2013, 02:17
by 8-bit
In my case, I use a utility called HotBackup.
After the backup of the pupsave file, I rename those backups adding "first,Second,Third,etc in the appropriate place.
And since HotBackup includes the backup date as part of the name, I know which is which.
After, I use a utility I wrote that restores the backup to the original directory.
On a reboot, I then have two pupsave files to choose from and just choose the restored backup and delete the other pupsave.
Of course, one could also just add a ".2fs, 3fs, or 4fs extension renaming the backup and use it unaltered with the backup date as part of the filename.
It would be easy to see just when the backup being used had been made.

Posted: Fri 16 Aug 2013, 03:33
by sunburnt
8-bit; But doesn`t it take a few minutes to make each backup?

mikeb; You have a "save folder option", instead of a "Save file". You cretin! That`s my idea!
It doesn`t take long to realize a folder`s better than an image file, more reliable. :wink:
But as image files go, a Squash file being R-O can`t be corrupted like a R-W ext3 file.

Posted: Fri 16 Aug 2013, 07:55
by 8-bit
If one created an SFS file from their pupsave file and mounted it after booting with "pfix=ram" any changes to existing files would not be done.
Puppy loads the linux kernel, the pupsave file then gets loaded as per instructions in the initrd.gz file. And then the Puppy SFS file is loaded.
This order of loading to me means that if a file exists, it is not overwritten by a later load of the same file.

Of course with a rewrite of the initrd.gz file, one could modify the way puppy loads so that a converted to SFS pupsave file loaded first and then the main Puppy SFS file loaded.

One thing that bothers me about a Factory reset file or folder is that in recovering from a corrupted pupsave load, the files causing the corruption would still be there as part of the user data and saved on shutdown or reboot with the result of the pupsave still being corrupted.

Posted: Fri 16 Aug 2013, 08:30
by sunburnt
8-bit; You can "append to a Squash file. So... You can write to it.
The folks who have used this have a button or control over "save" or "don`t save".
Where as my frugal live Save file is always available ( corruptible ).
And a USB boot, auto. saves at shutdown, and has timed saves too.

From my work on LanPuppy I found the Save file must load first.

If the Save file is wiped clean and restored to a "first boot condition", what corruption would there be left?

Posted: Fri 16 Aug 2013, 10:42
by mikeb
@Announcer
Actually your proposed system willl probably work fine assuming someone techie makes the initial files. I was questioning that instead of using your obvious abilities to provide a fix for a common (check the forum) problem of save file corruption perhaps you should divert your attention towards looking at better ways of saving on puppy...one idea does involve sfs since an archive is very robust ( who has ever has to replace the pup_xxx.sfs file?) but there are others. Dive into the core of puppy...remove the spaghetti and you never know what you might come up with. This forum is about the exchange of ideas.

@sunburnt...
You have a "save folder option", instead of a "Save file". You cretin! That`s my idea!
Hmm name calling lol.. funky bunny is the expression you are looking for.
Well actually slax gave me the idea as it does more or less that. By using a save folder you get the save partition idea but in a neater way. Advantage is you have oodles of room without those precarious 2GB save files I see in use. I use it for all our regular systems apart from on the netbook as it has plenty of ram and I can turn off the hard drive once booted using sfs. (with tidiness and sfs for apps saves run in at 30-60mb uncompressed) As for copyright I did this 3 years ago ...ha! Ooo and for fun have an pupsave like file used like a full install...ie no union...think of emulators...so low ram etc but can run from ntfs/fat. I left multisession alone as thats quite neat a it is. Oh yes I scrapped the usbflash mode 13... seemed silly to me and sfs suits it well.

On a general note remember puppy loads sfs files backwards normally (yeah sorted that too :D) so any additional sfs are 'underneath' the main one ...a pain in the neck at times so that's why I changed it... but it may affect any proposed 'recovery' system using the standard sfs loaders.

don't let the bedbugs bite

Mike

Posted: Fri 16 Aug 2013, 20:09
by sunburnt
mikeb; Back atcha funky bunny. :lol:

announcer; Suggestion, perhaps your app. could bring the dir. idea to Puppy.
Have an option in it to setup a Save dir. instead of a Save file.
And an option to transfer the contents of an existing Save file to a new Save dir.
A check if there`s a Linux partition to use would be needed of course.
Then your "Factory Restore" could do it`s work on either type of Save setup.

Wacha think? Am I being to optimistic, or have I got your interest?
Many I`ve talked to think the dir. idea would be an advancement for Puppy.
.

Posted: Wed 21 Aug 2013, 12:16
by Announcer
I've updated the first post with a slightly revised version of the script, which now has a "Cancel" option at start and a few failsafe checks to make sure everything's ok before it does anything.

Posted: Wed 21 Aug 2013, 18:28
by greengeek
Is this only intended for usb stick based puppies? Is there a reason it could not be used for a puppy installed frugally on HDD?

Posted: Wed 21 Aug 2013, 20:46
by Announcer
It might work fine with frugal HDD installs. But for my purposes, it's for usb sticks. (I haven't tested it with frugal HDD installs.)

Posted: Fri 23 Aug 2013, 10:11
by Announcer
Turns out all you need in a fresh savefile not to get a kernel panic at boot is the empty directory /etc/rc.d. So I've re-written the script, gotten rid of the sfs file it used to require, and edited the first post.

Should work on any Puppy with a savefile in use, and not need any editing.

Posted: Tue 03 Sep 2013, 21:20
by Q5sys
Nice little app.
For those who are talking about backing up your save file first... Use the pet that was posted here a while ago (I'll reupload it).
Works like a charm.
probably would be able to simply edit Announcers script to automate a backup before wiping if you really wanted a backup before his script erases the save file.
sunburnt wrote:Suggestion, perhaps your app. could bring the dir. idea to Puppy.
Have an option in it to setup a Save dir. instead of a Save file.
And an option to transfer the contents of an existing Save file to a new Save dir.
Many I`ve talked to think the dir. idea would be an advancement for Puppy.
.
But Puppy already has a save dir when its running. It's /initrd/pup_rw
All the save file does is compress that down into a single file for simple handling/encrypting/etc. You can simply back up your 'save dir' to wherever you want by just copying that folder elsewhere.

Or have I TOTALLY misunderstood what you were trying to explain?

Posted: Sat 13 Sep 2014, 03:13
by Announcer
This doesn't work anymore for recent versions of Slacko. :(