adrv, ydrv, etc.

[nic007]

greengeek. You don't have to unload your sfs's when you don't use a savefile/savefolder it vanishes like your pets. .

I am wondering why I have problems on my system then - the issue I get is that if I try to unmount my disks (which I always do manually before shutdown) I get a warning message that the kernel is still active and cannot release drives because of the sfs connection. Then I have to go hunting to remember which sfs files I loaded. It's messy and i don't have this problem with pets.

I never unmount anything before shutdown. The shutdown script does it for you (you can see it on the blackscreen after clicking the box that you don't want to create a savefile). BTW - If your sfs files are adrv, ydrv
, zdrv which are loaded into RAM, you can unmount any drives during a session. If your sfs files are loaded on the fly during a session, you must unload them if you want to unmount your drives and go on with the session....but if you are doing a shutdown, it's not necessary. You can easily unload all your sfs's with a single commandline using wildcards (or making a script).

[LazY Puppy]

This extra sfs option of fatdog is quite similar to of what I'm doing in my T.O.P.L.E.S.S. and its configuration files.

Hi RSH - maybe this question is in the wrong thread but I will ask it anyway - can you briefly explain why you have a preference for loading sfs'es?

If I understand correctly you don't use a savefile - just the original base puppy sfs supplemented with other sfs files.

If that is correct - why use sfs instead of pets?

I have no savefile and I like pets - after I shutdown they all disappear without the sfs problem of having to unload sfs files before shutdown. So what is it about your sysetm that you like sfs so much?

cheers!

From within a plain Puppy there is only one difference between .pet packages and .sfs modules. The .pet packages overwrites files during installation, the .sfs modules just don't, as they go to a layer below the main sfs.

Probably to install a .pet package is faster executed than to load a .sfs module by sfs_load.

In my setup I don't need to call sfs_load to load a .sfs module. I just go to the menu and click on the entry of the program that I want to use. This is only possible by my SFS P.L.U.S. applications that I'm using to create the RunScripts. Those RunScripts are doing the complete task of downloading (if locally not existing) and loading the .sfs module plus executing its program immediately after the .sfs module is loaded.

If the program of such .sfs module needs e.g. JAVA to run/work, I can define a JAVA .sfs module to be loaded after the .sfs is loaded but before the program is executed. So I just click on the menu entry of e.g. Lightzone and everything else is done automatically by the RunScript (which is called by the 'Exec=' entry in the .desktop file (the menu entry).

In my setup the Puppy is modified at bootup, so I got all the menu entries for the programs in .sfs modules already available.

You can check easily out, how this works in trying out A.U.D.R.E.Y.

I don't care about to unload .sfs modules before doing a reboot or a shutdown.

In the woof-ce puppies it is checked for anything being mounted. This will unmount automatically at reboot or shutdown. You can see this by mounting an .iso and mounting its .sfs module. Then reboot and you will see messages about the .sfs module, the .iso file and the drives being unmounted (unmount stray file systems - or quite similar).

A few years ago there was a discussion about unmount at reboot where I mentionend just to unmount everything mounted at reboot/shutdown and to make sure to unmount e.g. .sfs modules first as they could have been mounted from within a mounted .iso file. So the just added this.

[greengeek]

I don't care about to unload .sfs modules before doing a reboot or a shutdown.
In the woof-ce puppies it is checked for anything being mounted. This will unmount automatically at reboot or shutdown.

Thanks - I think then that my problem is that I am manually using pmount in an attempt to unmount my drives but it will not force an unmount until the sfs files are unloaded first.

If your sfs files are loaded on the fly during a session, you must unload them if you want to unmount your drives and go on with the session....but if you are doing a shutdown,

Yeah, thats my problem - sometimes I want to unmount my drives as a security measure and I get the same symptom then - pmount will not allow unmounting unless sfs files are disengaged first. Under those circumstances I can't rely on the shutdown routine as I am still intending to keep running.

I think I will stick mostly with pets. (Unfortunately I still have to use sfs method with devx until I find a way to make a Slacko 5.6 devx pet - tried it a couple of times but totally stuffed it up somehow)

Thanks for the info.

[nic007]

I don't care about to unload .sfs modules before doing a reboot or a shutdown.
In the woof-ce puppies it is checked for anything being mounted. This will unmount automatically at reboot or shutdown.

Thanks - I think then that my problem is that I am manually using pmount in an attempt to unmount my drives but it will not force an unmount until the sfs files are unloaded first.

If your sfs files are loaded on the fly during a session, you must unload them if you want to unmount your drives and go on with the session....but if you are doing a shutdown,

Yeah, thats my problem - sometimes I want to unmount my drives as a security measure and I get the same symptom then - pmount will not allow unmounting unless sfs files are disengaged first. Under those circumstances I can't rely on the shutdown routine as I am still intending to keep running.

I think I will stick mostly with pets. (Unfortunately I still have to use sfs method with devx until I find a way to make a Slacko 5.6 devx pet - tried it a couple of times but totally stuffed it up somehow)

Thanks for the info.

It's quicker to unload sfs files than it is to uninstall pets. For example a commandline/script like: sfs_load -u -c -q /mnt/sda1/*.sfs will immediately unload all your sfs files in the/mnt/sda1 parent directory...no popups or further steps required. To load on the fly you can use the same commandline/script without the -u option. Easy as. Also as a matter of interest: if you move your sfs files to somewhere in the running filesystem like /root and load it from there, you will be able to unmount your drives without having to unload the sfs files first.

[LazY Puppy]

It's quicker to unload sfs files than it is to uninstall pets.

It's just not necessary to uninstall a .pet package before being able to unmount a drive. Unloading a .sfs module seems to be necessary, though.

That's why I had included the Auto-Un-Load option to my SFS P.L.U.S., so I can define to unload a .sfs module immediately after its program has been closed and exited.

Also I do have option to have a script running in background that will observe the list of current running programs/tasks.

If activated, it starts unloading all loaded .sfs modules immediately when content of this list changes.

Since sfs_load can't unload .sfs modules if its program is still active, it will unload only those .sfs modules with inactive (not running) programs.

That's pretty cool, though mostly I don't use these options as I don't really have a need to unmount a mounted drive. If I will have such a need, I can choose to unload all .sfs modules just by a menu entry.

Though, my boot drive will never ever unmount as my T.O.P.L.E.S.S. Puppies needs to have the T.O.P.L.E.S.S. System SFS Modules constantly loaded.

Edit:

Back to topic: I have now established a new boot option to load my adrv, bdrv, cdrv, ddrv, edrv and xdrv .sfs modules in complete at boot up.

palldrv=y will load all those additional .sfs modules at boot up.

Edit2:

I forgot to mention in my previous post that I like also to use RoxApps (Rox Application Directories). When ever it is possible to use a program from a RoxApp, I just built one - lots of my JAVA based programs are RoxApps.