Hyperion Entertainment Message Boards

I'm using AmigaOS4.1 update 6 and found 2 issues with BRU:

1) When running like this:

> bru -c -Z

The program crashes with a GrimReaper. Basically the comression option -Z makes it crash.
I'm using the sys:emulation/amigadisks/workbench3.1/s/brutab

2) The interaction CON: window that appears doesn't respond to any keyboard input.
This is the version in AmigaOS4.1 that has an issue: "bru 52.1 (12/10/2006)"

And if I use the the version in the workbench3.1 directory, both of these things work okay. This is version
"bru 37.9 (05/01/1991)" that works okay.

I've been able to reproduce the problem on both classic and sam440ep. I was able to find an alpha version on Aminet from Fred Fish that has more info the -# debug option if bru compiled with the debug option.
---------------------

PS -- other notes not related to above:
a) I like bru since it will work across multiple volumes (but seems to be only tape or floopy) or it can create a single backup file from a volume with the -f option. However, it would be nice to have a fix to enable other things besides tape/floppy, like dvd/cd writable drives....

For example:
> mount rad:
> bru -c -f rad:
bru: "rad:": can't open archive: Is a directory

It doesn't recognize that it can use the entire volume and is expecting a filename....kind of weird.

On the otherhand this works:
> mount rad:
> bru -c -f rad:new

WIth a single file I don't think bru can go across volumes...need to check more though.

b) Is there any possiblity of releasing the "MODULE Kickstart/A4000T/ncr_scsi.device.kmod" to enable A4000T scsi -- I have many external scsi devices that would be nice to use with OS4.1 including some tape drives.

1) Is BRU a end-of-life component for OS4.x? With a few fixes it could be a good backup option. Even the GUI, HDBackup, from 3.x days seems to be working in 4.x. The HDbackup.help is in the sys:utilities but no OS4 version is there...wondering if there has been any thought of recompiling HDbackup from 3.x for 4.x PPC as well?

2)
Not sure how to upload a crashlog since the board gives me an error saying that #?.txt extension is not allowed. So I have I here:

Crash log for task "bru"
Generated by GrimReaper 53.5
Crash occured in module bru at address 0x1F8EF70C
Type of crash: DSI (Data Storage Interrupt) exception

Register dump:
GPR (General Purpose Registers):
0: 057582D5 3CEEF840 3D8F5464 3CEEF848 000031DF 00000A5E 3EC88000 00000000
8: 0000088C 00000048 00008034 057582D5 01188883 74657874 0F483C00 3D97DDD0
16: 09270000 9FF44630 09270000 3D1CB9B0 00124F80 3DF7BC40 088456B0 00000000
24: 3E240000 3CF48B42 4EC4EC4F 00000006 00000006 00000001 3CF48B3C 3CF48B42


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 2.2 0.45455 5.59136e+06
4: 2.53338e+06 1.89803e-95 3.05864e-95 7.29822e+25
8: 2.69082e+11 9.51836e+44 5.59136e+06 7.54268e+73
12: 1.01063e-80 0.05 9.34187e+20 7.54793e+168
16: 1.01328e+242 5.41484e-315 3.82347e+45 9.57173e-315
20: 4.56167e+257 3.99194e+252 6.22282e+175 2.59709e+161
24: 9.76517e+199 1.69355e+166 2.04738e+190 4.57033e-85
28: 8.56925e-315 5.95529e+228 9.30703e+242 2.11336e+214

FPSCR (Floating Point Status and Control Register): 0x32788000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0000F070
Condition (cr) : 0x44844C24
Instruction Pointer (ip) : 0x1F8EF70C
Xtended Exception (xer) : 0x00000000
Count (ctr) : 0x08820EF4
Link (lr) : 0x1F8EF6C4
DSI Status (dsisr) : 0x0A000000
Data Address (dar) : 0x3CF48B42



680x0 emulated registers:
DATA: 0000001A 000C6182 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 0927A10A 3DF08ED0 00000000 00000000 00000000 00000000 00000000 3CEEF6E0
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x1F8EF70C belongs to module "bru" (HUNK/Kickstart)

Stack trace:
module bru at 0x1F8EF70C (section 5 @ 0x196F0)
module bru at 0x1F8E8A54 (section 5 @ 0x12A38)
module bru at 0x1F8E8B08 (section 5 @ 0x12AEC)
module bru at 0x1F8DBA40 (section 5 @ 0x5A24)
module bru at 0x1F8DBB5C (section 5 @ 0x5B40)
module bru at 0x1F8DB934 (section 5 @ 0x5918)
module bru at 0x1F8E65B4 (section 5 @ 0x10598)
module bru at 0x1F8E63F0 (section 5 @ 0x103D4)
module bru at 0x1F8E6368 (section 5 @ 0x1034C)
module bru at 0x1F8DB864 (section 5 @ 0x5848)
module bru at 0x1F8D8CC8 (section 5 @ 0x2CAC)
module bru at 0x1F8EE928 (section 5 @ 0x1890C)
module bru at 0x1F8EF00C (section 5 @ 0x18FF0)
native kernel module dos.library.kmod+0x0002295c
native kernel module kernel+0x00045558
native kernel module kernel+0x000455d8


PPC disassembly:
1f8ef704: 7c0b0378 mr r11,r0
1f8ef708: 39290041 addi r9,r9,65
*1f8ef70c: 993f0000 stb r9,0(r31)
1f8ef710: 3bff0001 addi r31,r31,1
1f8ef714: 409effcc bne+ cr7,0x1F8EF6E0

Not sure if this program is one of them the OS4 devs would consider "save" to back up something?

I remember using it with 3.1 the first time, stumbling over it by accident.
It worked quite well, but i stopped using it due to the many drawbacks it had when it came to "modern backing up".

Fascinating that it's still there though

Was this BRU disbribation in OS4 just a mistake and wasn't suppose to be there? It was compiled for the PPC though and so seems like some work was done it....looks like though this is a low priority as not many have responded to the crash log.

my_pc_is_amiga wrote:Was this BRU disbribation in OS4 just a mistake and wasn't suppose to be there? It was compiled for the PPC though and so seems like some work was done it....looks like though this is a low priority as not many have responded to the crash log.

Everything was ported to PPC that we had source code for. You are the only person to actually use BRU that I know of. It certainly is not a high priority at this moment but it is on the to do list.

In the mean time, try using a 3rd party solution perhaps?

@ssolie

Everything was ported to PPC that we had source code for. You are the only person to actually use BRU that I know of. It certainly is not a high priority at this moment but it is on the to do list.

Since it's almost a year after the original posting of this topic, BRU must be a "really" low priority. There was a discussion over at Amigaworld.net where Andy asked if anyone knew of an archiver that would preserve both Amiga file links and protection bits (LHA doesn't preserve links). It was noted that "tar" won't preserve Amiga file links and Amiga protection bits either. Someone suggested BRU as a solution but the bugs that were reported in this topic remain. In addition, I couldn't get the BRU compression to work either. It would be very useful to have a BRU that would work without DSI errors, preserves file links and preserves protection bits. It could be used by program installers (including AmigaOS updates) in addition to being used as a backup tool.

My personal opinion is that if the OS4 developers are going to place file links in AmigaOS and the Amiga SDK, we should be provided with tools to accurately copy and backup those links.

@all
Bug about "bru -c -Z" already reported by Elwood year ago, and i update it with my own crashlog now. I do test it with debug.kernel and "munge", so two of the registers have DEADBEEF on moment of crashing, which mean we have accessed some memory after it has been freed (so should be not very hard to fix imho).

As for " The interaction CON: window that appears doesn't respond to any keyboard input.", if somebody will write step-by-step how to reproduce bug, i will check it and note to BZ as well.

kas1e wrote:@all
Bug about "bru -c -Z" already reported by Elwood year ago, and i update it with my own crashlog now. I do test it with debug.kernel and "munge", so two of the registers have DEADBEEF on moment of crashing, which mean we have accessed some memory after it has been freed (so should be not very hard to fix imho).

As for " The interaction CON: window that appears doesn't respond to any keyboard input.", if somebody will write step-by-step how to reproduce bug, i will check it and note to BZ as well.

The more I experiment with "bru", the more it looks like it needs a serious rewrite or replacement. I you enter "bru -h" in a shell, you will see that the copyright at the bottom indicates that it was written in 1988. You will also see commands mentioned and paths that give me the impression that bru is an ancient ported linux program.

The bru "interaction" console opens on your Workbench screen if there is a problem and bru needs some user input. Here is how I got the interaction window:
Check your Sys:S directory and remove a file named BRUTAB if it is there.
Write protect your system partition by entering something like: "lock dh0: on kas1e".
Enter "bru -c filename" in a shell.
You should see the bru interactive console appear on Workbench.
The interactive console doesn't seem to accept any input except Ctrl-C, which closes it.

The bru program can also look for floppy drives (DF0 DF1 etc.) and can fail if it doesn't find any. The floppy defaults should probably be removed. If you don't enter an archive filename with the "-f" option, bru might create an archive in the Sys:S/ directory called BRUTAB. Anyone who has been testing the bru program should look in their S: directory (Sys:S) and delete a file named BRUTAB if it exists.

It would be simpler to get rid of "bru" and replace it with something like a modified version of "tar" (name it AmiTar?) that preserves links and all Amiga protection bits. If users want a more sophisticated backup system that will do incremental backups, then they should look for a 3rd party solution as ssolie suggested.

xenic wrote:I you enter "bru -h" in a shell, you will see that the copyright at the bottom indicates that it was written in 1988. You will also see commands mentioned and paths that give me the impression that bru is an ancient ported linux program.

For anyone curious about bru's origins and present fate, check out http://www.tolisgroup.com/

I expect they have moved on to the extent that another AmigaOS port is not appealing to them, but you never know .

Best regards,

Niels

nbache wrote:

xenic wrote: check out http://www.tolisgroup.com/

I expect they have moved on to the extent that another AmigaOS port is not appealing to them, but you never know .

Best regards,

Niels

$40 US isn't out of the question for supported software. They do have PPC versions, albeit for the MAC.