BareBones 2.01r1 erased my previously full save-to partition

[rerwin]

I booted the BareBones 2.01r1 CD with "puppy pfix=ram" and checked out the SmartLink modem improvements, which worked without a reboot. When I rebooted, saving the new pup_save.3fs to a partition already containing a standard puppy2 (which I saw in rox before the reboot), the saved pup_save was not detected; when boot-up completed, I saw why. The partition that the pup_save was to have been saved to was empty!

In retrospect, I did not check the amount of free space available for the new pup_save, but I am sure it was less than 512MB but more than zero (in a 1GB poor-man-install partition). Also, I did rename the existing pup_save to pup_save-std.3fs, so that it would survive.

The only non-standard aspect of the actual reboot was that, as always, the software reboot caused the PCI SLmodem initialization to hang, requiring power-off and then power-on. That has never caused problems for puppy's integrity.

I subsequently reran the scenario using the now-empty partition for the pup_save. This time I was prompted to select a size for the pup_save file. Previously, I was not prompted for the size, so that should be a clue as to where things went wrong.

The difference was that originally the partition contained a puppy2 installation. Maybe BareBones concluded I wanted to save to an entire partition instead of a file, but I don't recall even being given the option of the partition-save. But then it would have saved something in the cleared partition.

UPDATE: I re-created the problem by saving to a full partition after booting with pfix=ram.

Richard

[rerwin]

Barry,

I have a possible fix for the problem of trying to save to a full partition. It simply does not display any partition that shows zero MB free space. Here are the changes to rc.shutdown:

#v2.0? Skip partitions with no free space.
if [ $AFREE -gt 0 ];then #v2.0?
echo "${ATAG} \"Filesystem: $AFS Size: ${ASIZE}M Free: ${AFREE}M\" ${AVALUE} \\" >> /tmp/schoices.txt
fi #v2.0?

The existing "echo" statement is just bracketed by an "if". The subsequent line begins with "#...weird, setting SCHOICES above".

With fewer choices remaining for the user, maybe the dialog box should allow the user to cancel the save operation if there is no acceptable space. Even better, if he could cancel the shutdown so he could find more space. Anyway, this fix should protect against inadvertant disaster.

I'm glad I found the problem before it impacts many others.

Richard

[BarryK]

Richard,
Thanks for finding that.
I have gone through rc.shutdown, put in a couple extra sanity checks also.
Will upload 2.01r2 soon.

[Flash]

... maybe the dialog box should allow the user to cancel the save operation if there is no acceptable space. Even better, if he could cancel the shutdown so he could find more space.

Richard

This would be a great comfort to users of multisession Puppy too. Very rarely (it's only happened to me twice, and I don't know if I caused it) when I go to shut down and the session should be saved, Puppy gives an error message instead. At that point there is no option that won't lose what's in RAM.

My workaround is to always use the "save" desktop icon to save the session if it is important, then simply shut down without saving. That way, if for some reason Puppy can't save the session I can cancel the operation and try to find the problem, without losing the session.

[darkerror05]

just an update, barry has uploaded barebones v2.01r2 with the bug fix. its here: ftp://ibiblio.org/pub/linux/distributions/puppylinux/ . For more info check: http://www.puppyos.net/news/ .