Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 27 Nov 2014, 10:17
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects » Next Puppy Development » 4.x
sfs files bug and problems in Puppy 4.1.2 and 4.2rc4
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [2 Posts]  
Author Message
gyro

Joined: 28 Oct 2008
Posts: 524
Location: Brisbane, Australia

PostPosted: Wed 11 Mar 2009, 14:28    Post subject:  sfs files bug and problems in Puppy 4.1.2 and 4.2rc4  

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:
  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:
  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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 524
Location: Brisbane, Australia

PostPosted: Fri 27 Mar 2009, 10:14    Post subject:  

The same problem occurs in Puppy 4.2rc4.

gyro
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [2 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects » Next Puppy Development » 4.x
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0605s ][ Queries: 11 (0.0146s) ][ GZIP on ]