AMI-Back crashes
  • Order of the Butterfly
    Order of the Butterfly
    matt3
    Posts: 387 from 2004/2/10
    AMI-Back crashes when writing the index file at the end of a backup.

    How can I work to resolve this?

    Here are my settings:

    Backup DH1: and DH2: to an Amigados file on the NAS. I tried writing the index to the S: (default) and RAM:.

    You have to turn turn off flash and beep for notifications or it will crash at the first beep.
  • »12.05.21 - 20:25
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    polluks
    Posts: 655 from 2007/10/23
    From: Gelsenkirchen,...
    What about Diavolo?
    Pegasos II G4: MorphOS 3.9, Zalman M220W · iMac G5 12,1 17"
    Power Mac G3: OSX 10.3 · PowerBook 5,8: OSX 10.5, MorphOS 3.15
  • »12.05.21 - 21:09
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    matt3
    Posts: 387 from 2004/2/10
    Way to painful to switch. I have used AMI-Back for 30 Plus years and built my entire backup system around it. AMI-Back works real sweet on 68k Amigas, including scheduling and automatically backing up, etc. My backups all work without me doing much and they are bullet proof.

    MOS does catch a guru that I say save. If that helps.

    [ Edited by matt3 12.05.2021 - 16:38 ]
  • »12.05.21 - 21:19
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    matt3
    Posts: 387 from 2004/2/10
    One other issue I ran into with Diavolo was it wouldn't backup across the network to a NAS (At least the latest 68k version).

    Too bad AMI-Back wasn't bought out and maintained to modernize the interface and fix this issue, it was developed over many years and really is a perfect solution for backing up.

    Funny thing is I seem to remember using AMI-Back many many years ago with my Peg II and a very old release of MOS and I think it worked. Not 100% sure on it.

    I actually tested a bunch of backup software many years ago(on the 3k) and here were my findings:

    Backup Software Review

    [ Edited by matt3 16.05.2021 - 09:18 ]
  • »16.05.21 - 14:16
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    matt3
    Posts: 387 from 2004/2/10
    Here is a quick update of what I found:

    I have got it working more reliably with the 1.3 version of AMI-Back and not 2.0. I have tried various version of the software and the latest (2.0i) seems to be the best. Right now it will run backup perfect one time or three consecutive runs and the fourth may fail. It fails right after the backup finishes.

    I found that PFS seems to be better than SFS for backing up and programs like wayfayer has crashes more often, perhaps because of the smaller files.

    I have many hours into this and hope to get it working at somepoint. Any suggestions are welcome!
  • »03.07.21 - 21:15
    Profile
  • MorphOS Developer
    Piru
    Posts: 500 from 2003/2/24
    From: finland, the l...
    Quote:

    matt3 wrote:
    AMI-Back crashes when writing the index file at the end of a backup.

    How can I work to resolve this?


    I spent some hours debugging this today.

    Ami-Back is unfortunately buggy in a way it handles subtask ("AmiBackTask") termination: rather than properly waiting for this subtask to terminate it makes an assumption about the task termination and FreeMem() the "struct Task" memory before the subtask has really terminated. This results in the task memory being re-used for other purposes while the task is still executing. If you're lucky the timing goes in your favour and the task manages to terminate before the memory is really reused. If you're unlucky this results in a complete system crash due to invalid memory references deep in the system scheduler (that the system can't recoverer from).

    There is unfortunately nothing that can be done to fix this is in MorphOS itself. The application would need to be fixed to prevent this crash.

    In particular the subtask would need to Forbid() before indicating the parent task about completion. This way the subtask would safely clean up before the parent task has a chance to run (and FreeMem() the subtask "struct Task").

    The Ami-Back application has always been buggy like this, but the probability of the crash getting triggered depends on the system: Less busy system with fewer memory allocations and running tasks might survive by luck. It also depends on the specifics of the system scheduler.

    Hence the application has better chances of running by luck on AmigaOS 68k system. Yet, if unluckly it will crash there as well.

    I'm afraid this is bad news in general if your backup solution is based on this application. I'm afraid there is no way to make it run reliably, unless if someone wants to take the task of fixing the application by binary patching it.

    [ Edited by Piru 04.07.2021 - 13:49 ]
  • »04.07.21 - 11:23
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    matt3
    Posts: 387 from 2004/2/10
    @Piru:

    Thank you very much for spending your time to resolve this issue for me.

    I will try and find someone who owns the source code for Ami-Back to see it may be a chance to get it corrected. I will also test some of the other programs on MOS and see if they run reliably enough. Funny it was the best one I tested on a 3000 when I wrote my review and have used it for 30 years and rarely had any issues with it. I was lucky indeed!

    Again thanks for the help!

    Matt

    Quote:

    Piru wrote:
    Quote:

    matt3 wrote:
    AMI-Back crashes when writing the index file at the end of a backup.

    How can I work to resolve this?


    I spent some hours debugging this today.

    Ami-Back is unfortunately buggy in a way it handles subtask ("AmiBackTask") termination: rather than properly waiting for this subtask to terminate it makes an assumption about the task termination and FreeMem() the "struct Task" memory before the subtask has really terminated. This results in the task memory being re-used for other purposes while the task is still executing. If you're lucky the timing goes in your favour and the task manages to terminate before the memory is really reused. If you're unlucky this results in a complete system crash due to invalid memory references deep in the system scheduler (that the system can't recoverer from).

    There is unfortunately nothing that can be done to fix this is in MorphOS itself. The application would need to be fixed to prevent this crash.

    In particular the subtask would need to Forbid() before indicating the parent task about completion. This way the subtask would safely clean up before the parent task has a chance to run (and FreeMem() the subtask "struct Task").

    The Ami-Back application has always been buggy like this, but the probability of the crash getting triggered depends on the system: Less busy system with fewer memory allocations and running tasks might survive by luck. It also depends on the specifics of the system scheduler.

    Hence the application has better chances of running by luck on AmigaOS 68k system. Yet, if unluckly it will crash there as well.

    I'm afraid this is bad news in general if your backup solution is based on this application. I'm afraid there is no way to make it run reliably, unless if someone wants to take the task of fixing the application by binary patching it.
  • »05.07.21 - 17:09
    Profile
  • MorphOS Developer
    zukow
    Posts: 602 from 2005/2/9
    From: Poland
    As Diavolo is available on MorphOS there is a chance that can be backported to 68k with features added.
  • »05.07.21 - 20:45
    Profile Visit Website
  • Butterfly
    Butterfly
    Georg
    Posts: 76 from 2004/4/7
    Quote:

    Piru wrote:

    There is unfortunately nothing that can be done to fix this is in MorphOS itself.



    Oh, maybe you can. You could have an option/tool to force certain apps (and/or tasks created by app) to run in cooperative task switching mode (== initial TDNestCnt is 0, instead of -1)
  • »06.07.21 - 06:00
    Profile
  • Cocoon
    Cocoon
    cip060
    Posts: 45 from 2010/7/30
    I don't understand what is the purpose of making a backup?
    Just have an external hard drive and copy the files from time to time
    or create an ISO
    I don't see why you have to go to such lengths to use a backup program
    when it is enough to simply copy the folders that we need to SAVE FOR EMERGENCY!
  • »06.07.21 - 09:40
    Profile
  • Cocoon
    Cocoon
    cip060
    Posts: 45 from 2010/7/30
    Once, backups were made on diskettes but in 2020 it is much easier to make an exact copy of the system and its data
    Obviously about morphos in this case


    [ Edited by cip060 06.07.2021 - 10:42 ]
  • »06.07.21 - 09:42
    Profile