Empty '.filetool.lst'

[Jason W]

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!

[Rich]

Hi Jason W

Ok, I hope I am not sounding terse, ...

Just sounded like some good old fashioned brainstorming to me.

[sm8ps]

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

[Jason W]

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.

[sm8ps]

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.

[Jason W]

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!

[sm8ps]

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. 

[sm8ps]

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!

[Rich]

Hi Jason W

No clear way to distinguish between a file with spaces and one with text.

How about this:

Code: [Select]

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:

Code: [Select]

busybox grep -c "^$\|^\s\|^/" /opt/.filetool.lst

[Jason W]

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.

[Rich]

Hi Jason W
In that case, maybe approach it from the other direction and test for the existence of characters. Maybe something like:

Code: [Select]

busybox grep -c  '[a-zA-Z]' /opt/.filetool.lst

[gerald_clark]

WORDS=$(wc /opt/.filetool.lst | awk '{ print $2 }')

[sm8ps]

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) with counting words sound good to me.

[Jason W]

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.