Symlinks aren't saved; original files are restored

[woodymnt]

Hi. I'm having trouble creating symlinks. Say, I install Gimp. The tray indicator of how much space I have in my pupsave goes from 265 to 175M. So I see the bulk of the installation went into /usr/lib/Gimp and /usr/share/Gimp. First I copy those folders to a partition on my usb plug that is formatted to ext2. Then I delete the two Gimp folders from /usr/lib and /usr/share.. Then I drag the folders I copied to those places and create links to them. Everything works fine, but when I reboot saving the pupsave I don't regain any space. The two Gimp folders are back intact in place of the symlinks.

EDIT: It would make much more sense to have Gimp and its deps in an SFS file that gets loaded at startup. -Thanks

[`f00]

Hi woodymnt

Did you install gimp from a dotpet? Make a backup of ~/.packages/<gimp-pkg>.files to check ppm's uninstall manually (possibly after a reboot if needed). Uninstall via ppm (Puppy Package Manager).

Yep, sfses work well for keeping savefile slim'n'healthy

sszindian reports a gimp sfs that works nice in latest precise, others should be available if that's not your version ~or~ you can roll your own with dir2sfs..

Hope that helps & Welcome to the kennels

[woodymnt]

Thanks f00. I use Lucid and found a great Gimp sfs for it here.

So thats good but I still have the same problem: When I try to make a symlink to keep the pupsave to a minimum, the target is always back where it was after save and reboot. I'm formatted to ext2, and the symlink is on the same partition. It must be something stupid I'm doing wrong but I can't figure out what it is.

I copy what I want to symlink to its destination outside of the pupsave, then I delete the original contents from the filesystem and replace that with a symbolic link to the destination. After save and reboot the contents are back in full, with the symlink still there inside the folder that reinstated itself.

[`f00]

You shouldn't need symlink(s) for an add-on sfs in /mnt/home - it takes up no space (in your savefile) other than whatever personal config you've done to gimp. An add-on sfs does show as part of the filesystem when it's mounted via bootmanager or an sfs utility like sfs_load (on-the-fly).

If you want to examine what's really in your savefile (and perhaps modify the savefile directly), use the bootcode "puppy pfix=ram" for a pristine environment (savefile and extra sfses not loaded). Navigate to /mnt/home (which is itself a symlink to your home partition) and click-mount your savefile in a rox window.. It's easy enough to keep track of where you are since the path has some '+' marks in it. Don't forget to click-unmount the savefile when you're done. Reboot->NoSave or make a new small savefile (kind of handy to have more than one if you want to keep some basic settings or do backup work).

Yeah, it took me awhile to get the gist of how things work (sfs, un/install and so on) - so as long as you have backup you should be fine to play about.

[Bruce B]

I don't yet understand why the problem. I've attached a pic showing the commands I used to make and display a test. It worked just as I expected.

The colors will show a good symlink and a broken one, where the red shows a missing source file for the link.

If you want to run the commands I'd want to know if it worked as it worked for me or if something else happened. If so, what?

Also consider some symlinks are relative and others absolute. The example shows relative links.

An absolute (path) link is different and whould require me to give the absolute path.

ln -s /mnt/sdw2/deletefile.txt

with the symlink named deleteme.txt being made in the current directory.

~

[woodymnt]

Bumping this because I found a workaround and failed to post it here. I solved the problem by mounting the pupsave from another puppy and deleting whatever I wanted to link from it that way. To do this type:

Code: Select all

mount /mnt/sdxX/(name of)pup_save.2fs /mnt/data -o loop

Thanks Bruce for trying to help. I was too embarrassed to get you clarify what you wanted me to do.

[mikeb]

snapmergepuppy does not handle this properly ..thought you might want some insight

mike

[SFR]

The problem is that after moving the directory outside of the savefile and symlinking it back, we have a situation where the directory is still in the savefile (/initrd/pup_ro1/), but in tmpfs is symlink.
So, during saving the session, cp (used in snapmergepuppy) will refuse to overwrite a directory with a symlink.
BTW, perhaps it's possible, but I haven't found a way to force cp to overwrite a dir with a symlink...

A simple workaround could be:
1. Move the directory outside of the savefile.
2. Save the session (this will delete the dir from the savefile).
3. Then create the symlink in place of moved directory.
4. And save the session again.

Greetings!