Tiny Core Base > TCB Q&A Forum
Reboot with "backup" causes error if .filetool.lst is empty - but it shouldn't?
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:
--- Quote from: baz on January 10, 2010, 01:33:41 PM ---@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.
--- End quote ---
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:
--- Quote from: tetonca on January 10, 2010, 08:01:57 PM ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version