RFC: a better backup naming

  • hallo

    I often stumble over the naming scheme of LE's backup, e.g.:

    20211024002341.tar

    even when there are more then one backup in the directory and watching that from a distance of some meters

    RFC:

    it would be better readable if it would be one of:

    2021-10-30_00:45.tar => echo $(date +%F_%R).tar

    or

    2021-10-30_00-45.tar => echo $(date +%F_%H-%M).tar

    or

    2021-10-30_0045.tar => echo $(date +%Y-%m-%e_%H%M).tar

    comments/rotten fruits ? :/

  • I wouldn't mind adding machine info to the backup filename, especially with multiple LE devices flying around.

    rpi4b-le-9.2.8-20211024002341.tar

    rpi4b-le-10.0.0-20211024002341.tar

  • IIRC the format is checked in the code. Making it nicer may result in to many complaints.

    the "make-up" could be made off again.

    something like:

    echo 2021-10-30_0045.tar|sed s'/-\|_//g'

    => 202110300045.tar

    the two numbers for the seconds are still left, but there is for sure a sed command to add '00' for the seconds (assuming no one will distinguish backup's on an second base) ...


    I wouldn't mind adding machine info to the backup filename, especially with multiple LE devices flying around.

    rpi4b-le-9.2.8-20211024002341.tar

    rpi4b-le-10.0.0-20211024002341.tar

    the problem I (many ?) have is the readablility of the date/time string.

    I guess the date in front is a plus when sorting ...

    Edited 3 times, last by GDPR-7: Merged a post created by JoeAverage into this post. (October 30, 2021 at 12:51 PM).

  • comments/rotten fruits ?

    I prefer the current format (%Y%m%d%H%M%S), it makes sense, is very readable. I deal with data files typically all the time that contain this exact timestamp format in their filename, it is a pretty common approach and is generally done sort you can easily sort the list of files by timestamp.

    I agree with Klojum, if anything it would be useful to indicate some additional details such as a device unique identifier (maybe hostname, mac, or sn). I personally don't know if I would care about a device type, if I had a unique identifier, but I could see LE version being useful especially when you don't want to make a mistake of pushing a 9.2 backup to 10.

  • format (%Y%m%d%H%M%S), it makes sense, is very readable.

    disagreed

    not on an 24" screen from a distance of ~2 m (I guess not only for elder people with(!)/without glasses) !

    the only need is to decide what's the oldest backup to subseq. remove it and therefore the current format is very hard to read.

    and - I guess - no one will usually sort backup files.

    and if:

    those mostly sitting in front of the screen and if that's the case a "ls -lt" is a friend to find the oldest backup...

    proof it yourself:

    move away to a distance of 1,5 m and decide which one is the oldest (don't look before !!! 8) )


    20211024002341.tar

    20211024002241.tar

    20211024002341.tar

    20211024002342.tar

    20211024003341.tar

    Edited once, last by GDPR-7 (October 31, 2021 at 8:58 PM).

  • not on an 24" screen from a distance of ~2 m (I guess not only for elder people with(!)/without glasses) !

    This is not a typical distance/screensize combination. Have you ever seen someone being 2 meter away from a 24" screen in an office or home situation?

    and decide which one is the oldest

    Without looking: the top one, when the files are properly sorted.

  • This is not a typical distance/screensize combination. Have you ever seen someone being 2 meter away from a 24" screen in an office or home situation?

    Without looking: the top one, when the files are properly sorted.

    are we talking about LE as an TV/Mediacenter Software for usually viewing TV/media's from a distance > 1.5 m or

    are we talking about a computer workplaces with a usually work distance of ~0.5 m for e.g. feeding this forum, etc ?

    *I* watch TV on an 24" Monitor from exactly (measured) 1,5 m

    - enough is enough, no need to waste more electrons -

    thanks, running my test

    the sort order is as is /laid out !

    (therefore ?!) I'm sorry to say: you were wrong, but proofed(?) :-/ my RFC is *valid* and *makes sense* ?!

    Edited once, last by GDPR-7 (November 1, 2021 at 12:32 AM).

  • As there are many opinions and standards for dateTime formats around the world the best option (and likely the only one project staff would accept) is to support the current behaviour as default so nothing breaks on upgrade for existing users, but offer a custom filename option that supports free text and date % variables so people can define their own format if they prefer, whatever that might be.

    As this touches our settings add-on, the main challenge will be finding a Python person to code/implement the changes :)

  • You are the one who asked for comments, but if you think argumentative is the way to go then good luck with that.

    I disagreed with your statement "is very readable".

    the main challenge will be finding a Python person to code/implement the changes :)

    I had that in my mind, but not that it would break something.

    anyway, I'll do what I ever do, cause of the indistinguishably of that date format:

    remove all backup's and create a new one, cause I only need them to go back, if something breaks.

    I'll mark this thread a s "solved"

    Edited once, last by GDPR-7 (November 3, 2021 at 3:26 PM).