Tiny Core Linux
dCore Import Debian Packages to Mountable SCE extensions => dCore X86 => Topic started by: sm8ps on May 08, 2015, 04:34:28 AM
-
Could somebody please have a look at http://wiki.tinycorelinux.net/dcore:basic_desktop_installation?&#persistence (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!)
-
Why would you run a backup without backing anything up?
-
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.
-
touch /opt/placeholder
Add opt/placeholder to .filetool.lst.
-
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.
-
Hi Rich
Re the /backup_done flag
What happens in the case of ~/.profile backup=0 ?
Sent from my iPhone using Tapatalk
-
Hi coreplayer2
From my .profile:
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:
/etc/sysconfig/backupwhich is probably what determines if a backup should be run.
-
What is the point of "| tee /etc/sysconfig/backup >/dev/null" ?
Why not just ">/etc/sysconfig/backup" ?
-
Hi gerald_clark
Possibly a remnant from an earlier version that had used more than one file destination?
-
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.
-
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?
-
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.
-
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.
-
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?
-
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.
-
Ok, I hope I am not sounding terse, just trying to figure out what we are wanting to do in what situation. :-)
What you just said is very easy to code in, and makes sense. And at the beginning of filetool.sh, will be very simple to give something like this:
If empty /opt/.filetool.lst or does not exist /opt/.filetool.lst; then create /opt/.filetool.lst if needed and then echo "opt/.filetool.lst" to /opt/.filetool.sh so it will back up itself otherwise empty and not interfere with reboot.
I can do that tonight.
Oh, and thanks sm8ps for your time you are spending with dCore and your effort to improve it. Keep it up!
-
Hi Jason W
Ok, I hope I am not sounding terse, ...
Just sounded like some good old fashioned brainstorming to me. :)
-
What you just said is very easy to code in, and makes sense. And at the beginning of filetool.sh, will be very simple to give something like this:
If empty /opt/.filetool.lst or does not exist /opt/.filetool.lst; then create /opt/.filetool.lst if needed and then echo "opt/.filetool.lst" to /opt/.filetool.sh so it will back up itself otherwise empty and not interfere with reboot.
That sounds very reasonable to me. Nice twist to have "/opt/.filetool.lst" in '/opt/.filetool.lst'!
Oh, and thanks sm8ps for your time you are spending with dCore and your effort to improve it. Keep it up!
You are very welcome. Same to you!
Cheers!
sm
-
There is a catch. A zero length file is different than a file with 2 or more blank lines. So with a test for the file being greater than zero length, or for the word count, empty spaces are different than just a blank file. No clear way to distinguish between a file with spaces and one with text.
I will be honest, this is not something I wish the spend days on as it has never been an issue before in the over 10 years that the this backup routine has existed.
-
There is a catch. A zero length file is different than a file with 2 or more blank lines. So with a test for the file being greater than zero length, or for the word count, empty spaces are different than just a blank file. No clear way to distinguish between a file with spaces and one with text.
I will be honest, this is not something I wish the spend days on as it has never been an issue before in the over 10 years that the this backup routine has existed.
I fully see your point. Let's close the issue! Thanks for giving it that amount of thought, though!
On the wiki-page, I included the recommendation to at least add "opt/.filetool.lst" into an otherwise empty '.filetool.lst'. That is fully 101-compatible. ;)
-
I remember long ago Robert saying that the entries in /opt/.filetool.lst had to not begin with a front slash and it was the user's responsibility to enter them that way. They of course also need to be existing and the file not empty.
Thanks for having this in the wiki!
-
It is mostly there already. Though, I intend to set up some pages about the basic functionality (sce-{load,import,remove}, .filetool.lst, seboot.lst etc.) that should provide the information in condensed form. The respective section is already put up on the welcome page. I yet have to master the subject for myself. 8)
-
Upon second thought, I have decided against keeping '/opt/.filetool.lst' in the persistence mechanism. The problem is that this file may change quite often and if one should exit the system by 'reboot' then the changes would be lost. I shall rather be using some dummy file instead.
Sorry to revive this non-issue!
-
Hi Jason W
No clear way to distinguish between a file with spaces and one with text.
How about this:
busybox grep -c "^$\|^\s" /opt/.filetool.lstIf there are any blank lines or lines that start with a space, the count returned won't be zero. You could even flag leading slashes:
busybox grep -c "^$\|^\s\|^/" /opt/.filetool.lst
-
Thanks for the code, I will ponder putting it into a routine.
But blank lines existing in an otherwise correct .filetool.lst do not cause error. So testing and exiting for a blank line existence will keep some folks who can backup without error from backing up.
-
Hi Jason W
In that case, maybe approach it from the other direction and test for the existence of characters. Maybe something like:
busybox grep -c '[a-zA-Z]' /opt/.filetool.lst
-
WORDS=$(wc /opt/.filetool.lst | awk '{ print $2 }')
-
Jason, I suppose you have taken a closer look at the code. At this occasion, I would like to mention the following difference between the graphical logout/backup tool and the console command backup.
The graphical tool spits out an error message for an empty '.filetool.lst', referring to '/tmp/backup_status'. However, the console command finishes silently in the very same situation.
I suggest including the same tests to the console command as the graphical logout/backup tool supposedly runs.
That said, I still support the idea of checking for an empty '.filetool.lst', seen that others seem to be interested as well. Thanks to Rich and gerald_clark for the specific suggestions! My work-around with a dummy file seems rather clumsy.
Combining the logic you outlined on May 9th (http://forum.tinycorelinux.net/index.php/topic,18393.msg112162.html#msg112162 (http://forum.tinycorelinux.net/index.php/topic,18393.msg112162.html#msg112162)) with counting words sound good to me.
-
Uploaded to release. Simply creates /opt/.filetool.lst if not existing, if blank or no text then echoes it's own entry as to prevent error.
The existing options for backup already create enough safety in dealing with the backup routine other than the blank or non existing /opt/.filetool.lst.