210 Please idiot-proof the pfix=ram shutdown (solved)

[PaulBx1]

My wife's Windoze computer died, so she ventured onto my Puppy machine. When she booted up she ran into the menu for selecting multiple pup_saves because I have more than one, but she selected 0 which boots into ram. Then when shutting down she picked "save" which wrote over my pup_save (at least I'm guessing this is what the sequence of events was). I lost 20 days of work, including a fair number of unread emails, back to the last backup of my pup_save.

At first I thought a solution would be for the shutdown to see if a pup_save is out there, and if so, ask if it should be overwritten. But for naive users, this is not safe enough, I think. Instead it should simply refuse to overwrite an existing pup_save file. Let the files be managed externally to this process by moving, copying, deleting and renaming.

This event also makes me think we need some script to run in the background at a low priority (perhaps invoked in rc.local) that automatically makes a backup copy of the pup_save each day, so that at most one day of work can be lost when something hiccups or a "stupid attack" occurs. That would be a big help for people like me who don't remember to do backups often enough.

[BarryK]

What version of Puppy are you using.
If I recall rightly, the latest does have such protection, although it has an issue, discussed elsewhere.

[PaulBx1]

It was 2.10r1. However since that happened I decided to go to 2.11.

If there was protection, she managed to defeat it, but I'm sorry I can't say how.

[Béèm]

I change always the name of the pup_save file after a safe from a ram session, in this way dayly work can't be overwritten. Besides this I take a copy in which the date and time is reflected as well.

@PaulBx1: Change wife (joke)

[Dougal]

I'm usig 2.10r1 and it didn't overwrite my pup_save.
Did it overwrite one with a different name (i.e. pup_save1 etc.)?

I wrote the code so it checks for each name it's gonna use, so it'd be good to know how it happened...

[pakt]

Dougal, I have run into some strange behavior that may be due to your mod.

To see the symptom, try this:

On a PC with an existing pup_save.3fs file (from any 2.xx), boot 2.11 with 'puppy pfix=ram', make some changes, e.g. save a dummy file or two in /root then choose to reboot.

When Puppy asks to make a pup_save file, answer 'yes' and a new file (pup_save1.3fs) is created. Ok so far.

Now boot 2.11 again, this time with no options and choose to load pup_save1.3fs.

Here is where the problem shows up - the pup_save1.3fs file is pristine - no files have been saved from the previous session.

I reported the bug here: http://www.murga.org/~puppy/viewtopic.php?t=11700
Paul

[PaulBx1]

I'm usig 2.10r1 and it didn't overwrite my pup_save.
Did it overwrite one with a different name (i.e. pup_save1 etc.)?

I wrote the code so it checks for each name it's gonna use, so it'd be good to know how it happened...

Before she got into this trouble, I had two pup_saves: my good working pup_save.3fs, and an older experimental pup_save_crypt.3fs, both 512MB. When I got back to the machine there was still the pup_save_crypt.3fs (I haven't looked at it actually, to see if it's unchanged), my working pup_save.3fs had turned into a pristine one, and there was also a small (32MB I think) pristine pup_save1.3fs.

<later>
On reflection, I should say it appeared my working pup_save.3fs had turned pristine. It is also possible, I suppose, that it was still good, and that when I booted and selected pup_save.3fs, it gave me pup_save1.3fs instead. I'm pretty sure I did not accidentally select the wrong pup_save, because I booted again to make sure I didn't...

[Pizzasgood]

You can mount the save-file manually to check, if you aren't trusting Puppy.
mount /mnt/home/pup_save.3fs /mnt/data -o loop

[Béèm]

Ok, I did some testing and found odd behavior.
For the record, I was testing with 128MB pup_save files and puppy 210r1. No pup_save.3fs present

1 boot in ram
- config keyb, xorg
- save to pup_save

2 reboot in ram
- config keyb, xorg
- copied a test dir in /root
- save pup_save as pup_save1.3fs
(I am not sure as things scrolled quickly by, but I think I saw a messages: saved to pup_save.3fs)

3 - reboot
- selected pup_save1.3fs
- had to do config of keyb and xorg
- copied test dir not in /root

4 reboot
- strangely it was Windows XP that booted

5 - reboot
- selected pup_save.3fs (not pup_save1.3fs)
- test dir was in /root

6 reboot
- selected pup_save1.3fs now
- test dir was not seen in /root

7 - reboot
- selected pup_save1.3fs again
- test dir was seen now in /root

Conclusion:
Test dir was copied only one.
It is as well seen in /root of pup_save.3fs as in pup_save1.3fs
A second reboot was needed to see the change.

[PaulBx1]

I was looking at this bit of code in rc.shutdown:

Code: Select all

#fitzhugh found this problem...
 #v2.10 Dougal provided code to save with different name...
 #[ -f $SMNTPT$SAVEFILE ] && return 1 #save file already exists.
 if [ -f $SMNTPT$SAVEFILE ]; then
  dialog --yes-label "SAVE" --yesno "There already exists a pup_save.3fs file on the partition you chose.
To create another one, with a slightly different
name (such as pup_save1.3fs), select <SAVE>.
To quit without saving, select <No>" 0 0
  [ ! $? -eq 0 ] && return 1
  local BLA=1 ; local SFFIX=`echo "$SAVEFILE" | tail -c 5`
  while [ -f $SMNTPT$SAVEFILE ]; do
   SAVEFILE="/pup_save$BLA$SFFIX"
   BLA=`expr $BLA + 1`
  done
 fi

A couple of things occur to me, to ask about (sh programming is certainly not my forte).

The variable SAVEFILE seems to be used before it is initialized, both at the beginning where the dialog is, and in the while loop.

I notice with the "tail -c 5" we are assuming a suffix in the form ".xxx" exactly. That is, .3fs1 won't work, but .xyz will. Is that what we want? If we want .3fs only, then we shouldn't be doing "tail -c 5"; we should only use ".3fs" or a fixed variable that is initialized up front and contains the same thing.

I also wonder about case. It is known that USB flash memories do strange things to filename case. Will this code work for something like that, without problems?

Just some thoughts...

[Dougal]

The variable SAVEFILE seems to be used before it is initialized, both at the beginning where the dialog is, and in the while loop.

Code: Select all

It is initialized earlier in the script. Inside the loop it's the same variable.

[quote]I notice with the "tail -c 5" we are assuming a suffix in the form ".xxx" exactly. That is, .3fs1 won't work, but .xyz will. Is that what we want? If we want .3fs only, then we shouldn't be doing "tail -c 5"; we should only use ".3fs" or a fixed variable that is initialized up front and contains the same thing.[/quote][/quote]

I had to add that because if you save to floppy (...) the pup_save file has the suffix .2fs.

Beem: This is really strange what you got... I'm thinking it might not be my code that's to blame, maybe somewhere else in the script (or in the script that saves the FS, snapmergepuppy or something) the name pup_save.3fs is used instead of the variable?

I'll have a look at it later. 

Pakt: I didn't notice your original message since it was labeled 2.11beta...
I think whar Barry wrote there is quite similar to what I wrote above. I'll try and find where the trouble is.

This is a strange thing...

[Dougal]

Got it!

After we choose to save to a file, choosepartfunc and then pupsavefunc are run (line 522):

Code: Select all

    choosepartfunc && pupsavefunc && PUPMODE=128 #v2.02 128=yes, save it.

choosepartfunc ends with (450-3):

Code: Select all

SAVEFS="`echo "$SCHOICES" | grep "^${SAVEPART}" | tr -s " " | cut -f 2 -d ':' | cut -f 2 -d " "`"
 SAVEFILE="/pup_save.3fs"
 [ "$SAVEPART" = "fd0" ] && SAVEFILE="/pup_save.2fs"
 PUPSAVE="$SAVEFS,$SAVEPART,$SAVEFILE"

which sets PUPSAVE to be something like "ext3,hda3,/pup_save.3fs"!
Then, in pupsavefunc, we change SAVEFILE and create an empty file with the new name, but don't change PUPSAVE!

So then (576-80):

Code: Select all

if [ ! "$PUPSAVE" = "" ];then
 SAVEFS="`echo -n "$PUPSAVE" | cut -f 1 -d ','`"   #f.s. and partition where pup_save.3fs is located.
 SAVEPART="`echo -n "$PUPSAVE" | cut -f 2 -d ','`" # "
 SAVEFILE="`echo -n "$PUPSAVE" | cut -f 3 -d ','`"
fi

uses changes SAVEFILE back to pup_save.3fs!

The solution: before my "fi" (line 259) we can add:

Code: Select all

PUPSAVE="$SAVEFS,$SAVEPART,$SAVEFILE"

Another solution: move my entire function (with the SMNTPT tests from the beginning of pupsavefunc) into the end of choosepartfunc (before line 453).

[PaulBx1]

Good to hear you found this problem.

It is initialized earlier in the script. Inside the loop it's the same variable.

Ah, must be done in a called function. I searched backward from that point with geany and didn't see it.

What are the restrictions on naming the pup_save? Is it that the first 8 characters must be exactly "pup_save", the last 4 can be either ".3fs" or ".2fs", and between those two sets of fixed characters, anything goes?

In "How Puppy Works" Barry implies a single file named "pup_save.3fs". Apparently written before the notion of multiple pup_saves was introduced.

I guess if the filename uses only lower case, then we shouldn't run into problems with USB flash changing the case. So maybe that should be another restriction.

[pakt]

Got it!

Good news, Dougal

I'll test it later today.

What are the restrictions on naming the pup_save?

Yes, that is something I would also like to know.
Paul

[pakt]

Regarding pup_save.3fs - I just thought of another trap that I've fallen into a couple of times.

The scenario: I boot another version of Puppy 2.xx from CD and I already have a pup_save.3fs file from a previous 2.xx.

If I either miss the 5 second timeout or forget to add 'puppy pfix=ram' and the Puppy version I'm booting is newer than the one used to create pup_save.3fs, that file will be upgraded whether I like it or not. I have lost a few setups that way.

I would like to be asked at this point IF I want pup_save.3fs to be upgraded or not. If not, then Puppy should run as if started with 'puppy pfix=ram'.

Then on shutdown or reboot, a new 'pup_saveX.3fs' can be written if so desired.

Make any sense?
Paul

[Pizzasgood]

I'll second that, and even third, fourth, and fifth it if I need to (I'll call upon my buddies Me, Myself, and I. Togeather we four form the Three Pizzateers).

The main reason I'm using 2.11 right now is that I messed up both my save-file and my backup save-file (in a moment of stupidity, I renamed the backup rather than copying it...). Not that I didn't intend to upgrade eventually, but I really didn't want to yet. I was going to hold out until 2.12 to save the time of having to re-install everything (no way my poor abused save-files could hold up through an upgrade, especially involving newer gtk and x11).

[Béèm]

If I understand well, newer release could have to use newer/other libraries or programs. So what worries me is, that when using a pup_save from earlier releases one has to add thing to get a newer release working but the old not needed stuff is still there and thus the pup_save file is only growing.

It would ne nice to have a real upgrade faclity, which removes not needed stuff after adding the new versions.

Any comments?

[pakt]

[quote="B

[GuestToo]

i have tried to keep most of my packages as independent of Puppy's system files as possible ... for example, i can often put everything, binaries, libraries, help file, etc etc, all in one roxapp folder ... if my package does not put anything in /usr, it does not alter the system files and there is no problem ... to "uninstall" my package, just delete the roxapp folder

[Dougal]

It is initialized earlier in the script. Inside the loop it's the same variable.

Ah, must be done in a called function. I searched backward from that point with geany and didn't see it.

The "running" of the script actualy starts waaay down towards it's end... You were looking in the function definition which is above it.

What are the restrictions on naming the pup_save? Is it that the first 8 characters must be exactly "pup_save", the last 4 can be either ".3fs" or ".2fs", and between those two sets of fixed characters, anything goes?

Yes, the init script searches for pup_save*.3fs.
When I was trying out the idea of getting pup_save files on different partitions recognized (using dummy pup_save files), I tried all kinds of names and it worked with things like pup_save-bla.bla.3fs.

All these comments on the woes of upgrading reminded me of something:
I don't use pup_save to keep any personal files. I consider pup_save as "disposable" -- that's one of the things that are great about Puppy.
It also allows you to have the few pup_save files for different purposes.

You all know this, but here's another idea:
Say you want to have your emails in the /root/.mozilla directory. What about if you move that directory into /mnt/home (or some other partition that's mounted at startup) and create a link into /root?
If that works it could allow you to use the same .mozilla directory with different pup_save files!

It might even be possible to move the entire /root directory into /mnt/home, then you can keep your desktop tweakings between different pup_save files!

If anyone is willing to try it...