Hello Guest, if you are reading this it means you have not registered yet. Please take a second, Click here to register, and in a few simple steps you will be able to enjoy our community and use our OpenViX support section.

View Entry Info: Enigma2 Timeshift Bug

Category:
Possible Bug
What ViX Image build number are you using?
Please provide your ViX Team image build number. Menu > Information > About > Build number > ENTER THIS NUMBER e.g. 4.2.028
5.2.034
Have you tried a flash WITHOUT settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
No
Have you tried a flash WITH settings restore?
Have you tried this? PLEASE SELECT YES OR NO.
No
Attachments
Results 1 to 11 of 11

Thread: Enigma2 Timeshift Bug

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Title
    Junior Member
    Join Date
    Apr 2014
    Posts
    6
    Thanks
    0
    Thanked 6 Times in 3 Posts

    Enigma2 Timeshift Bug

    Hi there,

    Am fairly confident I've uncovered a longstanding bug (regression) with time shift that should be a fairly easy fix. I've proved it by downloading the enigma-src and adding further debug to the code.

    I say regression because the part of the code in question suspiciously has a commented line with a different check commented out to be replaced by something that definitely isn't working.

    If you trawl the forums you'll often run up against people complaining about the error message that they have to format their drive with ext2/ext3 to support hard links and sure most of them probably screwed up but there are a minority like me that have done things correctly but have been affected by this bug which makes them feel they've not formatted their drive correctly when in reality it's a totally misleading error message. So...

    In:

    https://github.com/OpenViX/enigma2/b...s/Timeshift.py

    At about line 884:

    # if filename.startswith("timeshift") and not os.path.splitext(filename)[1]:
    if filename.startswith("timeshift") and not filename.endswith(".sc") and not filename.endswith(".del") and not filename.endswith(".copy"):

    We are effectively checking to make sure we don't enter this part of the code for certain file extensions but what is happening is we are not checking for ".ap" files and for some reason (of which I'm not quite sure), sometimes on rare occasion one of those exists and is being processed here. So that later when we try to do:

    os.link("%s%s.sc" % (config.usage.timeshift_path.value,filename), "%spts_livebuffer_%s.sc" % (config.usage.timeshift_path.value,self.pts_eventc ount))

    .. with an .ap file it is actually trying to hard link a "ap.sc" file which will never exist! (It's either .ap or .sc) causing the os.link to fail and the exception to think that it just can't make a hard link because of the drive format whereas in reality, it shouldn't be processing this .ap file.

    The fix seems simple (but maybe implemented better by someone more familiar with this code), to add 'and not filename.endswith(".ap")' to the end of the 'if' statement at the top and to add a delete for old '.ap' files with all those other deletes just below it.

    Hope this helps! This is working well for me and should help people out with the occasional error about hard links and ext3 formats. Happy to chat over.

    Cheers.
    Last edited by vampyrebat; 25-03-19 at 23:55.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
This website uses cookies
We use cookies to store session information to facilitate remembering your login information, to allow you to save website preferences, to personalise content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners.