Empty '.filetool.lst'

[sm8ps]

Could somebody please have a look at http://wiki.tinycorelinux.net/dcore:basic_desktop_installation?&#persistence? I have my doubts about the handling of an empty '.filetool.lst'.

The situation arises in the following scenario: I have set up the installation from scratch with persistent home and opt on a dedicated partition. At first boot, '.filetool.lst' does contain "home" and "opt". Since persistence for those directories is not needed, I clean out that list.

Issueing 'backup' terminates without error. The graphical log-out dialogue, however, complains and points to '/tmp/backup_status' which contains "tar: /opt/.filetool.lst: No such file or directory". The file does exist but is empty, which must mess up a command line in a script.

I tried 'filetool.sh -b' which throws "sed: /opt/.filetool.lst: No such file or directory" but then says "Backing up files to .../tce/mydata.tgz".

The graphical 'filetool' throws "dc: stack underflow" and "ash: invalid number ''" (that is an empty string between two apostrophes) when performing a dry-run. Asked to perform a backup, it throws "sed: /opt/.filetool.lst: No such file or directory" and "tar: /opt/.filetool.lst: No such file or directory".

There still is need for the backup mechanism as there may be configuration files outside '/home' or '/opt' that should be made persistent, so the norestore boot-code cannot be used.

Is there a better strategy than the one presented in the wiki which seems a bit round-about?

Maybe the tools should check for an empty '.filetool.lst' and act appropriately? (I have not studied the code yet, sorry!)

[curaga]

Why would you run a backup without backing anything up?

[sm8ps]

I see the point in your counterquestion. Though, I am approaching the issue from a different direction.
When setting up persistent home and opt an hard-disk, there is no need for backing up these folders. Thus one may clear out '.filetool.lst'. However that does not mean that one will not need to back up configuration files. In the course of setting up the system that need will eventually arise. So the backup mechanism should be left in place, albeit with an empty list in the beginning.
Of course, there are several ways to handle this situation. I am looking at it through the eyes of new-comers who are not acquainted with the nuts and bolts of *Core and I am seeking the simple-most way of setting up dCore.
IMHO the case of an empty '.filetool.lst' is valid. It might be easy to handle if the scripts included a check for an empty file. Though, I do not know if this might have any undesirable effects.

[gerald_clark]

touch /opt/placeholder
Add opt/placeholder to .filetool.lst.

[Rich]

Hi sm8ps

It might be easy to handle if the scripts included a check for an empty file.

I think a check for an empty file would be a good idea.

Though, I do not know if this might have any undesirable effects.

/opt/shutdown.sh  looks for a flag called  /tmp/backup_done  which is created after running a back up.

[coreplayer2]

Hi Rich
Re the /backup_done flag
What happens in the case of ~/.profile backup=0 ?



Sent from my iPhone using Tapatalk

[Rich]

Hi coreplayer2
From my  .profile:

Code: [Select]

export BACKUP=1
[ "`id -un`" = "`cat /etc/sysconfig/tcuser`" ] && echo "$BACKUP" | sudo tee /etc/sysconfig/backup >/dev/null
If I'm reading it correctly, the second line creates:

Code: [Select]

/etc/sysconfig/backupwhich is probably what determines if a backup should be run.

[gerald_clark]

What is the point of "| tee /etc/sysconfig/backup >/dev/null" ?
Why not just ">/etc/sysconfig/backup" ?

[Rich]

Hi gerald_clark
Possibly a remnant from an earlier version that had used more than one file destination?

[Jason W]

Common Core/dCore functionality was taken from Core during 5.x, may not be the same as Core.  I will look at this and see when I get in tonight.

[Jason W]

The backup functionality is the same in Core as dCore, but for changes to pathname prefixes like /bb versus /bin.

My thoughts are that the same basic functionality on this should be shared across Core and dCore, base functionality should only differ when absolutely necessary.  So if we want to change this in Core we should in dCore, or vice versa.  That way users can easily use on or the other and not have to change habits.

When I run the command that is used to tar up mydata.tgz, when I use full tar it just creates an empty archive when .filetool.lst is empty.  When busybox tar is used, it just echoes an error of empty archive and no archive is created?

Is that not really the same end result?  No data in an archive on reboot to unpack?

[Rich]

Hi Jason W

When busybox tar is used, it just echoes an error of empty archive and no archive is created?

Is that not really the same end result?  No data in an archive on reboot to unpack?

When using the GUI to exit, failure of the backup causes the exit to abort.

[Jason W]

Ok.  The dc and ash errors are due to entries in filetool.lst that are non-existent.

Will take some hacking but some tests can be put in that will make it more error proof in the case of entries that do not exist.  I am less concerned about an empty filetool.lst, but very possible for a typo in an entry in that case which the entry should be ignored by dc and anything that will make it bork.

I will work on this, and then if Core wants the changes it would be simple to plug in.

[Jason W]

Ok, if there is even one entry in filetool.lst, tar errors occur and the backup status is echoed to /tmp/backup_status.  Or if filetoo.lst is empty, empty archive error is echoed to that file.

Is that not a great degree of safety when one thinks they have made all the right entries in filetool.lst yet there is a typo or similar?  Rather than have the reboot proceed and those files lost to the reboot?   If there is a wrong entry in filetool.lst, then reboot will not occur by the graphical exittc which novice users will be using, giving them a chance to correct the entry/entries and save their data.

So what is the desired reboot behavior then if there are errors in the filetool.lst or it is empty?  Reboot anyway and possibly lose data, or bork an allow the user to save his data and fix the situation.  Or here are we only concerned if filetool.lst is empty and not concerned about errors in the file?

[Rich]

Hi Jason W
Ideally, if there is an error in filetool.lst (leading backslash, non-existant file, etc.) then reboot/shutdown should abort. If filetool.lst
is empty, presumably it's because nothing needs to be backed up so reboot/shutdown should proceed as normal.