sfs files bug and problems in Puppy 4.1.2 and 4.2rc4

Post Reply
Message
Author
gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

sfs files bug and problems in Puppy 4.1.2 and 4.2rc4

#1 Post by gyro »

1) The released desktop icons are like ghosts in the machine, they never quite go away.
Delete one of the default set of desktop icons as per the release, e.g "console". Reboot puppy, it stays deleted as expected, and will remain so through as many reboots as you like.
But, add or remove an sfs file via "BootManager" and lo, it's back.
I consider this a definite bug. When I delete a desktop icon I expect it to stay deleted, not re-appear at some later unexpected time just because my deletion happens to be inconvenient to the OS.
You can see the same bug in action, if you change the path of one of these icons, e.g. change the path of "console" to "/usr/bin/sakura", (of course after having installed "sakura"). All goes as expected until you add or remove an sfs file via "BootManager" and lo, it's back. You now have two "console" icons on the desktop, the "/usr/bin/sakura" one and the original "/usr/bin/rxvt" one.

A work around:
In "/etc/rc.d/rc.update" change the code:

Code: Select all

  cat $NEWFILESMNTPT/root/Choices/ROX-Filer/PuppyPin | grep -v '<backdrop' >> /root/Choices/ROX-Filer/PuppyPin
  cat $NEWFILESMNTPT/root/Choices/ROX-Filer/globicons >> /root/Choices/ROX-Filer/globicons
to

Code: Select all

  if [ $NEWPVERSION -gt $OLDPVERSION ];then
   cat $NEWFILESMNTPT/root/Choices/ROX-Filer/PuppyPin | grep -v '<backdrop' >> /root/Choices/ROX-Filer/PuppyPin
   cat $NEWFILESMNTPT/root/Choices/ROX-Filer/globicons >> /root/Choices/ROX-Filer/globicons
  fi
Problem appears to be with the pile of code that seems to be executed when either the puppy version changes or the the list of sfs files changes. In both cases it resurrects the "PuppyPin" and "globicons" from pup_xxx.sfs. And then attempts to cleanup the resultant mess. If you haven't changed any of them, then everything's OK, but if you have, then your changes might survive this code, then again they might not.
My change to the code means that the "PuppyPin" and "globicons" from pup_xxx.sfs are ignored when the code is only being executed because of a change in the sfs files list.


2) When you add or remove sfs files using "BootManager", if you have more than one desktop icon with the same path, then only one will remain. The "duplicates" are deleted.
It might be argued that "rox" doesn't support "duplicates" so this is not a bug.
But "duplicates" actually work, and in some circumstances make sense. If you want to execute the same code, but with different "args", then it's easy to drag the same app to the desktop several times and edit the icons to have different "label"'s and different "args". e.g. a second "rox" icon on the desktop to go directly to an XP "My Documents" directory.
So it's still a pain when your "duplicates" work fine, until you start doing something completely unrelated, e.g. add or remove an sfs file via "BootManager", reboot, and all but one of your "duplicates" disappear.

Analysis:
It appears to be the same pile of code as per above, having just created a whole pile of duplicates, it then proceeds to clean up it's own mess. Apparently my stuff is acceptable co-lateral damage.

I really wish that Puppy could work in a way so that it doesn't play around with the PuppyPin file when just adding or removing sfs files.


3) pup_xxx.sfs takes precedence over anythingelse.sfs.
I created "bogus.sfs" which contains only a file called "/usr/sbin/pupdial" that does nothing except put up a message. After adding "bogus.sfs" via "BootManager", "/usr/sbin/pupdial" is still the original, it has not been overridden by my useless one. If I change the name of the file in "bogus.sfs" to "/usr/sbin/pupdialb" then it appears.
My interpretation is that "pup_xxx.sfs" is at the top of the pup_ro stack, where as I think it should be at the bottom.
The pain is that, if I produce software as a ".pet" I can override any file in the system because it goes into pup_rw. But if I produce software as a ".sfs" file then I can only add files that don't already exist in "pup_xxx.sfs", I can't override any of them.
I really hope I am wrong on this one.

Note: I investigated these problems on a frugal install of Puppy 4.1.2, dual booting on NTFS partition on XP machine. I then did quick tests on a frugal install of Puppy 4.2rc2, on the same machine.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#2 Post by gyro »

The same problem occurs in Puppy 4.2rc4.

gyro

Post Reply