.filetool.lst and .xfiletool.lst do not adapt to boot codes

[baz]

I am using a custom user=baz boot code and by default the .filetool.lst includes a line to backup home/tc which does not exist, and therefore causes an error.

As well, I am using persistent opt and home but .filetool.lst and .xfiletool.lst both still contain references to those folders which causes unexpected and unintended results.

Solution: These files should be created with consideration of different boot codes.

[jur]

These files are meant to be customised. Each setup would be different. Persistent /home and /opt does not need to be backed up if you don't want, but a non-persistent setup does need those and others.

Check out TCB tips and tricks; I posted a thread on this issue.

[baz]

These files are meant to be customised.

A new user who is on a new install should not have to debug a guaranteed error related to the fundamental function of rebooting the machine. This does not fall in line with the rest of how carefully TC is developed. At worst, leave those files empty if they are "meant to be customized" - not in a state specific to only to one type of many possible installs. Ideally of course, TC should implement a couple of IF statements to setup nice defaults for the user's system.

Persistent /home and /opt does not need to be backed up if you don't want, but a non-persistent setup does need those and others.

I agree completely, that's why they should be appropriate for the setup in question - not specific to one type of setup. It makes little sense for someone to backup home and opt if they are already persisted unless they know exactly what they are doing - and in that case they are an advanced user making advanced changes. The typical user will only see problems and conflicts. Defaults should be set to the most common and problem-free values.

[roberts]

Even if you opt to use a persistent home and/or persistent opt does not mean that you should not backup them up.  User's choice and decision if and when to do such, not more automation.

[baz]

User's choice and decision if and when to do such, not more automation.

Less automation would be very welcome here. Right now TC is doing too much by assuming a certain set of files should be backed up, when in a persistent install, they are highly likely not going to want those files backed up. But even more importantly, I feel I need to re-iterate this: TC IS BROKEN OUT OF THE BOX IF YOU SPECIFY A CUSTOM USER!

Even if you opt to use a persistent home and/or persistent opt does not mean that you should not backup them up.

Let's be honest here, there may be some edge cases where a user might want to do this, but in the vast majority of cases, it is pretty obvious that users are not going to want to create duplicate copies of their data, wait for those duplicates to be created on every shutdown, then figure which instance of their data is actually running - the persisted ones or the restored ones that temporarily overwrote the persisted ones on next boot.

My two cents with love.