Reboot with "backup" causes error if .filetool.lst is empty - but it shouldn't?

[baz]

My .filetool.lst and .xfiletool.lst are purposely empty. When I reboot, and the backup option is checked (by default) I receive an error because they are empty. I would prefer that it just backed up nothing for two reasons:

One, is that I would always like to make it a habit to backup and let my config files decide what, if anything, to backup, rather than changing back and forth and having to remember what state .filetool.lst is in.

Two, and much more importantly, let's say I previously used to backup something, but now I don't want to back it up anymore. It is very important to remove it from .filetool.lst and choose to backup, otherwise it will get restored on next boot. So the backup, in this case, is actually serving to un-backup. This works nicely in all cases, except when you no longer want to backup anything at all, now you have to manually delete mydata.gz. The flow of working changes just for this case.

To add, it seems that "backup" should be renamed to "skip backup" and unchecked by default, just to emphasize that backing up is the *normal* thing to do. Then let .filetool.lst decide what happens.

[roberts]

See the man page for tar: http://linux.die.net/man/1/tar
In particular the -T and -X options which are for the lists .filetool.lst and .xfiletool.lst respectively.
It does not make sense to have empty lists.

[baz]

Rather than tar'ing nothing, perhaps the backup could detect that there is nothing to backup, and delete mydata.gz for the user.

I am commenting from the user perspective, not the implementation perspective or the tar perspective. Regardless of how it works, does it not make sense for a user to consistently manage their backups in the same way?

[roberts]

Using a *nix system imples that some file management. This is not turnkey nor a windows like OS.

Too much automation is not good. You seem to not want to use the system as designed.
That is fine, but don't expect more automation to accomodate hybrid scatter mode installation as that is not the intended goal. We had not had an issue with backup/restore for over one year.

Re: User's perspective...
I would not expect a new user to be deleting all the items in a hidden system file, unless they had a  some knowlege of their inteded purpose.

I would never purposely delete a user's mydata.tgz file.

[baz]

I love TinyCoreLinux that's why I post so much to the forums! The last thing I want is a Windows like system.

In my opinion the system is designed amazingly - but that doesn't mean there isn't room for improvement. The TinyCore team are fantastic engineers without a doubt, but sometimes being so deep in the code makes one lose sight of the user perspective. Being a user, I aim to help provide some of that perspective. And all things being equal, it is fair to say that a better front-end experience will only benefit TinyCoreLinux. Of course "better" is very subjective, as is "all things being equal" because they never are but that's where a good discussion is helpful.

I don't claim to know everything, and I am perfectly happy to hear other people's point of view and change mine. I made a specific point about workflow using the .filetool.lst, and it is not consistent the way things are. If someone deletes all paths to be backed up, why would it be wrong to also delete the backup? They are saying they no longer want to backup, and remain consistent with how the system is designed in all other cases. Anomalies are generally not positive.

Again, I mean no awffence, and I am a big fan. It is because of that that I care enough to post

[maro]

I guess what might be helpful here (without changing the current functionality) would be an additional check of the /opt/.filetool.lst file after line 94 in /usr/bin/filetool.sh.

Something along the lines of:

Code: [Select]

  if [ $1 == "backup" ] ; then
    sed -i /^$/d /opt/.filetool.lst
+  if [ -s /opt/.filetool.lst]; then
     if [ -z $2 ]; then
and

Code: [Select]

        [ -s /tmp/backup_status ] && exit 1
      fi
+   else
+     echo -N "Nothing to backup due to empty /opt/.filetool.lst"
+   fi
    if [ -f /etc/sysconfig/bfe ]; then

Please note this is not a patch, but rather an (yet) untested idea.

[roberts]

It is not difficult to implement. But the idea of a user finding a hidden system file to delete its contents for the purpose of deleting their existing backup seems extraordinary. Perhaps a restatement of purpose is in order. Instead of trying to state what should be done, state the intended purpose. The goal. We already provided an option to not to default to doing a backup.

My interpretation was an expectation of an empty list should make an empty tar archive so that no restore would happen upon reboot and therefore the deleted item would not return. Which is quite different from just checking for an empty list.

The "skip_backup" boot option is "norestore", perhaps that is what is needed to be specified?
That way, when using persistent home & opt, an occasional backup could be performed and restore would only happen on demand, e.g., when norestore boot option is not specified.

[mikshaw]

My interpretation is that automatically deleting ANYTHING other than temp files is a bad thing.  Making assumptions about what the user wants should be done as little as possible.

[Jason W]

An empty .filetool.lst makes no sense, as it should at least back itself up.

And of course, it should always be assumed that /opt/.filetool.lst should contain at the very minimum "opt/filetool.lst" to back itself up to be available next boot.

Having only opt/filetool.lst listed in opt/filetool.lst would achieve what the original poster seems to want: to make an empty backup that overwrites the old backup instead of manually deleting mydata.tgz.

[roberts]

I will revisit this area for v2.9 with the possibilty of additional GUIs to help manage the two files .filetool.st and .xfiletool.lst  that control backup and restore. I will also port over my tiny GUI to support selective restores.

[baz]

To continue the discussion:

@Jason W: In a regular TC install that is very much true. In my case I have a persistent opt, tce, and home so anything in those folders, including filetool.lst itself, doesn't need to be included. I use it mainly for certain files in /usr.

@Milkshaw: This is an implementation detail. The TC team could have easily decided to use a group of files to manage backups, or a folder, or a binary file that gets created a through a gui. The end user simply wants to achieve the result of a backup, how ever the system does that is not the concern of the user. The thing is, the system currently does automatically delete files. If you remove lines out of filetool.lst, then do a backup, it will automatically delete those files from the contents of mydata.gz.

[tetonca]

@Milkshaw: This ...
The thing is, the system currently does automatically
delete files. If you remove lines out of filetool.lst, then do
a backup, it will automatically delete those files from the
contents of mydata.gz.

It's the user's responsibility to maintain archives of
mydata.tgz completely independently of the backup
scheme -- archival of its content is not provided for.

I generally keep half a dozen historical copies (snapshots,
as it were) on file, and make a deliberate archive of
the current one at least once a week.

That said, this file is created anew *every* time the
backup system is called into service.  That is an
act of creation.  What the system does not do (to
my knowledge) is save the old file as 'mydata.tgz~'
which seems the only reasonable response to your
thesis, from where I sit.  That way nothing would
get *cough* deleted, in your parlance.

No.  Modifying .filetool.lst is a deliberate act; it is an
instruction you've commanded.  It is your job to
understand that instruction.  It is the machine's job
to carry it out.

The nature of that instruction is never to delete; it
is always in the positive: 'save these, and only these
files -- I want them'.

You, yourself, do the 'delete' the moment you delete
a line from /opt/.filetool.lst.  That, is the destructive
act.  Fix *that*.


Backing up is itself an instruction to create.  The  proof
of that, is that the very first time it is commanded, a new
file, never before seen, appears: mydata.tgz!

The fact that it overwrites a previous instance of the
archival file is trivial; many system commands do the
same thing.  It is your job to understand this, not to
change it.  If you wish to change it, nobody can stop
you.

But you shouldn't.

[baz]

@tetonca: I completely agree with you. Especially when you say "Modifying .filetool.lst is a deliberate act; it is an instruction you've commanded." and "You, yourself, do the 'delete' the moment you delete a line from /opt/.filetool.lst." The filetool.lst is currently the provided interface to tell the system how and what to backup. If that happens to be 10 files, 1 file or no files, that is what the system should backup, and, of course, consequently restore. I started this thread because this works in all cases except when you go from 1 to 0 files, which unnecessarily breaks the provided interface/paradigm/philosophy.

[jur]

That said, this file is created anew *every* time the
backup system is called into service.  That is an
act of creation.  What the system does not do (to
my knowledge) is save the old file as 'mydata.tgz~'
which seems the only reasonable response to your
thesis, from where I sit.

That seems like a good idea - introduce the system where the existing mydata.tgz gets renamed. That will allow the user to recover from 'accidental' backups which have happened to me.

[tetonca]

baz, I appreciate the thought you've given this.

Let's hear what others will say on this.