persistent data

[coreplayer2]

@coreplayer2 the beautiful thing about the solution I presented is that if you don't want backups to automatically occur during shutdown, then a simple "echo 0 > /etc/sysconfig/backup" will prevent that from happening. 

There is already a solution;  Change Backup=1 to Backup=0  in  ~/.profile    then run backup

To be honest, I'm never happy being forced to "Opt Out" of anything.   The way I see it "Opt Out" should be the default (ie: backup=0). 
Ideally a backup mechanism which allows users
1. an option to maintain "Opt Out" status (being the default),  with
2. an option to "Opt In" one time
3. an option to "Opt In" on each shutdown
I assume these options could be integrated for both core (cli mode) and tinycore (gui mode)

just my two cents worth

[gerald_clark]

Do not attempt to make /etc persistent either through .filetool.lst or a bind mount.
/etc contains dynamic configuration files that are populated at boot time in response to boot options and installed packages.
Attempts to make /etc persistent will result in erratic operation and difficult to diagnose problems.
If you wish to modify files such as /etc/passwd, include those specific files in .filetool.lst.

[CentralWare]

@gerald: Though I'd agree with you, I also have to disagree in one aspect.

If you bind-mount a persistent /etc, the worst case scenario is you'll have "static" config files.
When you install additional extensions, they'll end up writing to this "static" location and their links will be saved statically.  The only down-side I can fathom is if you edit one and make a mistake, you have to manually go back and fetch the original if you don't keep revisions.

Boot codes: If you have multiple kernels/cores booting from the same device, then yes, /etc is a very bad idea as it would be "shared" between the different init files and more than likely wouldn't mesh well in some cases.  Otherwise, having ANY persisting directory from the tree being implemented merely takes a little fore-thought such as:

If you upgrade an extension, there's a chance the new extension (such as icewm) has different configuration variables, some of which could be deprecated and thus break the extension.  However, this applies to filetool as well.  (If MyData has configs from a previous extension, the same happens when it's extracted.)  Then again, this can be the case in virtually every distro.  (ie: RPMs which overwrite previous installs simply rename filename.conf to filename.rpm.conf and drop the new config file in place where you lose your changes, but still have the old copy, which is in our case as well - just the new copy doesn't take over, it stays in the tcloop/extension where it's nice and safe.)  TC really isn't made to handle upgrades as it is, at least not that I'm aware of, so this probably hasn't been overly problematic yet.

Now, I'm going to guess your reference to boot codes manipulating something in /etc is likely pointing at /etc/sysconfig.  (such as sysconfig/backup, desktop, etc.)  If this is your reference, then yes, I agree with you entirely; making a note of your intentions would likely have caused less guesswork as to what you were referring to.  I don't think tc-config writes anything to init.d so that one's pretty safe on its own whether it be dynamic or static.  This, too, could easily be remedied:
Copy sysconfig to /tmp/sysconfig (there's not all that much in there)
Mount static /etc
loop through the file list in /tmp/sysconfig
if [ ! -f /etc/sysconfig/$file ]; cp -a $source $dest; fi
then dump the remainder of /tmp/sysconfig
By saying "do not"...  that sounds a little too M$-ish to me.
This is Linux.  Everything is possible!   (With an ounce of foresight and a pinch of effort.)
For the every day NT (non-technical) user...  I don't recommend even stepping into /etc...  then again, for desktop-only users I don't recommend TC (as-is) as the learning curve is usually beyond the scope of their experience.  For the developer, tinkerer or just someone wanting to get their feet wet in the heart of 'nix...  I brag TC.  You can't get more "inside" Linux without all the "Fluff" that comes with main-stream so even as a learning base I think it's a terrific way to get started.

YES, I know it's not the core concept, so to speak...  but that's the beauty of concepts!  Even Robert could make changes to the conceptual design based on ideas coming his way, whether his own or someone else's...  then it just becomes the new "core concept."

Slight change of vocab suggested.  Instead of "Do Not" might I suggest "It's not recommended, because..."  I've read way too many posts on here where the attitude by some (and sometimes quoted) is "No! And if you don't like it - go somewhere else!" which is really self-defeating.  The only reason Robert launched TCL in the first place is because of that exact problem...  people being closed-minded and saying "No" to progress.

There's ZERO offense intended here and I'm in hopes you don't take any in the least; I'm just pointing out something I've noticed a few too many times and fall back to the number of ways to skin a cat (though I don't skin cats, so I don't see a lot of use with that analogy directly) but I can assure you, there's not much that can NOT be done, it's just a matter of looking at it from all aspects in order to find out HOW it should be done and then having the skill/knowledge to implement it.  Some of the greatest things this world has come to know is based on people going against the "No."

Take care and keep nixing!