I have used the flash-fix several times before - this seemed a different sort of critter.
It happened again this morning (I didn't keep messing till I got the "ps axl" message -
I just went straight to the hard-off power button)
both times have been during the routine of deleting stick1's .mozillza (KNOS's) with
stick2's .mozilla (my prefs).
The flash-fix itself just froze up as well.
This last time, I had not yet unmounted stick2 when the freeze occurred, and after the
reboot the .mozilla folder on stick2 had vanished - so I moved stick2 to the desktop to
copy it , and it showed as already there, and when I put it back into laptop now it shows.
Maybe when having to hard-off with power button prior to unmounting causes a hiccup -
which is fixed by removing and re-inserting the second stick.
Took me a little while to put two and two together on this one ...
I suspect that you're running up against some of our insane security which is causing this, and possibly your other weirdity as well. This stuff is a bit complicated, so I'll explain what I think is going on, what I had
expected and something that should get around this for now. Some of Windows and Linux' "ease of use" things that many might expect are not allowed in KNOS because they weaken security, and I wouldn't allow it.
BSD (and KNOS takes it a bit further) has insane levels of security, based on permissions, control lists and other "tokens" which are temporary. If
you create a file, document, image, whatever, you are the owner of that file and have exclusive permission to it. YOU can read, write, modify or delete that file. Each process has its
own ownerships, permissions and tokens to access those particular files. In KNOS we take it further by actually removing "system" or higher permissions than you in order to ensure that nothing you do in KNOS can attain levels of permissions that could be used to attack the system, and this philosophy extends to the day in the future when we finally get all of KNOS together to the point where I would personally permit it to actually be installed onto a hard drive. That day is still off in the future.
So in our design, we anticipated the need to copy off saved pages, documents, graphics and other things
you create in KNOS to a stick so that this important data can survive a reboot on that stick. However, because the stick is a
writeable device, our level of security is reduced simply because it an be written to. Therefore, by our design as well as design inherent in BSD itself, when a stick is inserted and a file is copied either to or from a memory stick, the
only permissions which can be copied are "KNOS user" and absolutely no others. Any other permissions copied either way are automatically destroyed in the copying process in order to maintain the highest possible security in KNOS. For obvious "security by additional obscurity" reasons, I won't go too deeply into the additional mechanisms I also designed in.
Anything
you create can be readily copied back and forth from a stick subject to those permissions and DACL strippings. Anything created by anything else though will
not have its permissions preserved. Firefox, Open Office and numerous other third party programs are known to have their own security issues from time to time and could serve as a means of somehow getting at KNOS' kernel by means of some unknown exploit. Therefore, any files created by these programs can be copied, but when copied back in will not have the proper permissions in order to be accessed by those programs once KNOS has copied them over KNOS' "known good" copies. There are additional traps to prevent files which are not owned by you from being tampered with by additional other means. This is all part of our design.
By copying over the entire ".mozilla" directory, you're copying in your stuff, but you're also copying over
other stuff belonging to mozilla as well as other things such as plugins. And when they're copied in, their permissions are lost and replaced with yours. As a result, those files no longer have the permissions they need in order to be read in and that in turn can cause programs which can't handle not being able to access those files to "spit the bit" instead of creating a replacement file or otherwise handling this event "gracefully." By our design, the only files that will survive a copy over are only those files which you created, and not any which were created by another program or possible exploit. We intend to keep things this way out of necessity.
Now as to your situation, I hadn't anticipated doing things that way. For our "cloud-based" method, this would all be handled by another mechanism that would properly back that data up after first stripping out areas which could possibly store a future infection and then saving only those specific files relevant to settings. This would allow settings and guaranteed "not-executable or exploitable" data without saving anything "risky" to the cloud. However, we don't have that side of our equation anywhere near "in operation" as yet. So in the future, this current inconvenience will be a non-issue.
For now, what I do myself is I save only the bookmarks to the stick (that's a personal file which only requires "KNOS user" permissions) and I write it out inside Firefox by going up to bookmarks, then select "backup and restore" and backup the bookmarks to the stick. When I run Firefox from a freshly booted copy, I insert the stick and restore from the *.json file I had saved in the previous session. That gets me back my bookmarks and I otherwise start clean. That always works because Firefox saves the bookmarks with
my permissions, and there isn't anything else in the .mozilla directory that I have any desire to backup. But that's just me.
Something that will work for you or anyone else who wishes to backup directories from KNOS (it's really not a good idea and does reduce your security should anything bad ever end up in there) would be to go into the "Home folder" in KNOS, then click on ".mozilla" to highlight it, then finally right-click that directory. Select "compress ..." This will bring up the tar.gz archiver. Be sure to change its name from ".mozilla" to something else (losing that "." is good enough). Select "save to" and point it to your memory stick instead of home or desktop. By doing this, KNOS will archive the entire directory and most importantly, it will SAVE all of the proper permissions and other security structures of ours inside that tar.gz file.
Then, next time you boot, go to that stick. Select that tar.gz file that you saved last time and doubleclick on it to open the archive. Set "Extract to" to the KNOS home directory and it will throw in the old one you saved on top of the new one KNOS made. However, be ready for an error when it's done because KNOS will
refuse to overwrite a pair of security files. You can ignore that error, it's just KNOS protesting and it absolutely will not allow those overwrites. However your Firefox data will all go back in and you shouldn't have this problem again because those various permissions will be safe inside this security wrapper and thus won't have to be obliterated when you do the write-back. Since the tar.gz has
your permissions, everything will work for you this way. I do this myself for my .Skype and .evolution directories although Evolution has a better backup and restore system built-in which actually works.
All of this was deliberately designed into KNOS though, and that's the reason why we thought the best solution to be having all of this stored on a KNOS-supporting cloud server - either ours, or an institutional server which supported KNOS users. We
might also come up with a custom version to do this on a stick in the future - right now, that's still up in the air depending on our ability to finance the next major steps towards mass release.
