i have been running Puppy for a few years ... the first version i tried, even the mouse wheel did not work
Puppy has improved a lot since then
in all that time, i have mostly run Puppy frugal installs on my hard drive
i have never installed Puppy "normally" to a dedicated partition (option 2)
i have never had a problem with file corruption, either of the Puppy read only file system or the Puppy save file ... that includes sometimes crashing Puppy (usually because i was doing something weird that caused Puppy to crash, my fault, not Puppy's fault)
How to run Puppy HD Installation in RAM? (as from CD)
-
Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
I've had some strange behavior with symlinks in 2.02 (it sticks a symlink to itself in the destination), and sometimes I have problems with moving things in the /root directory, but I've messed with this particular save-file and installation so much that I don't blame it for having problems. I probably messed something up somewhere. That's one of the reasons I start fresh with each update: I get a clean environment to break. 
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
if you unzip a symlink to a dest dir somewhere, then unzip the symlink again, the second time it will usually put the symlink in the dest dir that the first symlink is linked to
some of my packages do this, but they shouldn't ... most of my packages work properly
this is not really good, because what you get is a circular symlink, which is an infinite loop
most linux programs can handle a symlink that is an infinite loop ... Euphoria, for example, does not handle an infinite loop well, and usually a Euphoria program will stop if it encounters one
what i often do in a dotpup package that is going to unzip a symlink to a dir, is to rm the symlink first, like this:
rm -f /usr/share/streamtuner
this should rm a symlink, so unzipping the package will work properly ... if there is no symlink, nothing should happen, which is ok ... if /usr/share/streamtuner is a real dir, rm -f won't delete it (but the package will put an infinite loop symlink in the dir)
if you are aware of the problem, you usually can easily make sure your symlinks get installed properly
some of my packages do this, but they shouldn't ... most of my packages work properly
this is not really good, because what you get is a circular symlink, which is an infinite loop
most linux programs can handle a symlink that is an infinite loop ... Euphoria, for example, does not handle an infinite loop well, and usually a Euphoria program will stop if it encounters one
what i often do in a dotpup package that is going to unzip a symlink to a dir, is to rm the symlink first, like this:
rm -f /usr/share/streamtuner
this should rm a symlink, so unzipping the package will work properly ... if there is no symlink, nothing should happen, which is ok ... if /usr/share/streamtuner is a real dir, rm -f won't delete it (but the package will put an infinite loop symlink in the dir)
if you are aware of the problem, you usually can easily make sure your symlinks get installed properly
-
Pizzasgood
- Posts: 6183
- Joined: Wed 04 May 2005, 20:28
- Location: Knoxville, TN, USA
They were symlinks I made, no installer involved. As in I linked /mnt/blahblahblah/CustomIcons to /root/CustomIcons, but then there appeared another symlink inside the CustomIcons directory pointing to the real CustomIcons directory (and named CustomIcons). Once, there was a script in a directory named the same as the directory, and this error happened and overwrote the script with the symlink. Otherwise it hasn't bugged me much.
I think it's just my save-file though. I'm hard on my Puppy installs. I plan to repartiton my harddrive with a more logical layout around the time 2.11 comes out, so I'm just going to stick with my buggy setup until then, then start a fresh save-file with 2.11 in a partition with a lower number so I don't have to edit initrd.gz just to boot my system (no /dev/sda9 in initrd.gz).
Speaking of installing though, would "cp -R -H whatever/ /wherever/" have problems with symlinks?
I think it's just my save-file though. I'm hard on my Puppy installs. I plan to repartiton my harddrive with a more logical layout around the time 2.11 comes out, so I'm just going to stick with my buggy setup until then, then start a fresh save-file with 2.11 in a partition with a lower number so I don't have to edit initrd.gz just to boot my system (no /dev/sda9 in initrd.gz).
Speaking of installing though, would "cp -R -H whatever/ /wherever/" have problems with symlinks?
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
[img]http://www.browserloadofcoolness.com/sig.png[/img]
if in doubt, i would make a simple test or 2, to see whether it's actually doing what you think it should be doing ... especially if it's Busybox
cp -H applies to symlinks on the command line
if you want to control how cp treats symlinks as it is copying, i think the options are -d and -L
i have had problems with cp -a ... i did some tests, and found that it doesn't always copy files i think it should
for example, i used cp -a to copy a dir, with and without -u ... then deleted a file or 2 from the dest dir ... i would think it should recopy the missing files if the command is run a second time, but it doesn't seem to replace the missing files ... at least sometimes ... at least the last time i tried it ... maybe i didn't get the syntax right, but in any case, i couldn't seem to get it to do what i wanted
another thing, find may not find files you think it should find, because of unionfs ... i find the -noleaf switch helps, but it's slower
so, if in doubt, it's probably a good idea to experiment with a few simple test cases
cp -H applies to symlinks on the command line
if you want to control how cp treats symlinks as it is copying, i think the options are -d and -L
i have had problems with cp -a ... i did some tests, and found that it doesn't always copy files i think it should
for example, i used cp -a to copy a dir, with and without -u ... then deleted a file or 2 from the dest dir ... i would think it should recopy the missing files if the command is run a second time, but it doesn't seem to replace the missing files ... at least sometimes ... at least the last time i tried it ... maybe i didn't get the syntax right, but in any case, i couldn't seem to get it to do what i wanted
another thing, find may not find files you think it should find, because of unionfs ... i find the -noleaf switch helps, but it's slower
so, if in doubt, it's probably a good idea to experiment with a few simple test cases