Curious to see what that window was about, I ran quickpet again, which reran the update progress window again. This time, I looked at the "glibc" window and told it to update the "glibc" file. Then it hung with the "processing" splash displayed. I noticed then that my pupsave space was down to 1 MB! When I right-clicked on the "personal storage"tray icon, it disappeared. I tried the "Resize" menu entry, which did not respond. So I powered down with the PC's power button.
I had begun with 5 pupsave files (all 4fs) and was running #3 in the list. During the reboot, I was offered only the first 2 of the set! Using the second of those (64 MB), I booted and immediately resized it (to 128 MB) and did not update it. I displayed the tahrpup directory and found that the name of the file that I quickpet-updated is renamed with a substitute character of hex E80C (instead of the "h" in tahrsave...). Two other files (4 and 5 in the list of 5) are missing altogether. Even more alarming, though, is that 2 other files, tahr64saves, also have their names modified, one with "E80C" and the other with "E80B" -- for different letters in different positions within the file names.
When I attempt to rename the damaged file names, I get:
Code: Select all
root# mv ta?rsave-602test3.4fs tahrsave-602test3.4fs
mv: cannot move ‘tarsave-602test3.4fs’ to ‘tahrsave-602test3.4fs’: Input/output error
root#
To possibly confound things, the tahrpup directory resides in an NTFS partition. But I have not used windows on it for a long time. Attached is a screeny of the directory.
For now, I think I will go back to using 2fs savefiles, since I think I have seen some concerns about 4fs. I hope that is not a factor. But I wonder if the quickpet update process might be ignoring (or not seeing) an out-of-memory condition and writing outside of the pupsave file.
(later) Now I know what is meant by the gliibc update possibly damaging puppy. But this goes beyond the current puppy and affects other files, too..
Update 8/22/16: After running XP to check for damage to the NTFS partition, I found that the names have been returned to the correct characters, even though the checker reported no errors.