De-tarballing

Guys, Trying to decompress some downloaded tarball files (e.g. bootapps) but getting checksum errors e.g.

tar: directory checksum error (61100 != 85554).

Have attempted with tar from command line as well as UnTarBZ2 app.

What am I doing wrong?

thanks.

Make sure the downloaded file has /tar/bz2

on the end

And make sure you are not trying to use UnTarBZ2 to extract the contents of any .zip files. The clue is in the name! You should use a tool such as SparkFS or SparkPlug to extact zipfile contents.

The “collection” tarballs are a bit odd because they are a .tar.bz archive containing a load of .zip archives. The only reason I’ve done it like this is because it’s very easy for me to package up the prebuilt stuff on our site, each of which is already inside a zip file.

Thanks Ian – added /tar/bz2 to the filename and it worked.

And thanks to ROOL guys for the hard work, have reflashed my Iyo with 5.14 successfully!

• cvs-repos.tar.bz2
• UnTarBZ2 v.1.01
• C Library 5.57 (26 Nov 2010)
• SharedUnixLibrary 1.11 (15 Oct 2007)

bunzip2: Caught a SIGSEGV or SIGBUS whilst decompressing
[...]
UnixLib detected recursion of SIGSEGV.  Exiting.

UnixLib detected recursion of SIGSEGV.  Exiting.

[Edit: (1) Maybe it’s a problem with UnixLib, so I’ll try reverting to 1.10 (10 Apr 2006), as included with NetSurf… (2) Well, that didn’t help, either!]

In order to satisfy my curiosity, I’ve extracted CVS (the current ‘2011-02-10 04:06:50’ archive) under Linux. Something seems to be up, but as it appears to be just docs, I guess I shouldn’t be too bothered:

tar: Record size = 8 blocks
tar: cvsroot/castle/RiscOS/Sources/Lib/HTMLLib/Doc/Done?,v: Cannot open: Invalid argument
tar: Ignoring unknown extended header keyword `hdrcharset'
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Ignoring unknown extended header keyword `hdrcharset'
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Ignoring unknown extended header keyword `hdrcharset'
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Exiting with failure status due to previous errors

[Edit: Of course, Linux isn’t exactly going to help in terms of retaining filetypes! Anyway, it’s now going better, back under RISC OS with alignment exceptions turned off.]

That’s interesting, I thought there was something fishy about my shared lib thingy. Untarballing simply wouldn’t work on my xM but does run under VRPC. Thought my module might be corrupt and downloaded a fresh one from riscos.info instead. Even though I’m now using a mint ROOL !boot untar quits with the above message and DosBox still shuts down when I want to go fullscreen. This is without any additional modules apart from FrontEnd installed.

How about from the command line? Meanwhile, the xM seems OK-ish for me but strangely not on the Touch Book. I’ll double check with booting from the same boot drive on each some time this week hopefully. Also, when it fails, the option to retry (typing ‘y’) works from the CLI but the desktop window doesn’t seem to take the input focus so can’t be tried there. Again, I really need to confirm a couple of things but as we’re sharing issues here I thought I’d mention it.

I have renamed the file “Done?,v” to “Done,v” in the CVS repository. Hopefully, this will help with the tar issue you found. Because it’s just a bit of documentation, this rename operation shouldn’t break anything(!) And as far as I can see, it’s the only file in the repository with a ’?’ character in its name.

Thanks for that. Using the UnTarBZ2 frontend, I had a “not found” error with mixed/RiscOS/Sources/SystemRes/Internet/Resources/bin/Attic/X,ffc. There seems to have been no such problem with extraction of the same archive via the CLI.

Another question: what’s supposed to happen with the filetypes and suffixes? Mine all seem to be retained. I probably shouldn’t need to use something like Retype, should I?

Additionally, I don’t seem to have all the files listed in the web CVS Root. The (previously downloaded) ‘cvs-repos/tar/bz2’ file has a size of 55068581 bytes. This seems to be right. The total size of the contents of the extracted directory is 315408573 bytes (20029 files).

I think I’ll have to return to square one.

UnixLib detected recursion of SIGSEGV.  Exiting.

That seems to be related to attempting the UnTarBZ2 with alignment excpetions not turned off. I’ve also tried to variously experiment with/without installation of the C tools 32-bit libraries etc. (as turning alignment exceptions off/on didn’t seem to help every time). Anyway, as it can take a long time to see the results, I’ve not arrived at a conclusive situation.

However, I’ve now used the CLI UnTarBZ2 in a TaskWindow to successively unbzip2/untar both ‘cvs-repos’ and ‘src-omap/5/17’ [1] in the same session, i.e. with the same settings.

• My ‘cvs-repos.cvsroot’ contents of subdirectory ‘castle / RiscOS / Sources / Desktop / TaskWindow’ (to cite one case as an example) are as per the live CVS source repository… but the files are all type &fff and suffixed by the desired filetype and ‘v’, e.g. ‘MkClean,fd7,v‘
• My ‘src-omap/5/17.OMAP3Dev’ contents of the subdirectory of the same name have the correct filetypes and no suffixes (the Attic directory is missing but that’s probably of no consequence).

AIUI the full sources are required in order to set up the build environments etc. In any case, something seems to need investigating, please.

Note that something which would help assist testing is smaller example tarballs, containing just a few files from each build process. This would mean they could be tested without having to wait half an hour or more before seeing the results (unless UnTarBZ2 can be safely Escaped with all the filetyping routines etc. still being executed).

So, if anyone has the time/inclination to confirm any of the above, a bug report can be logged. (Note, this was all done on a v1 TouchBook, but apparently that shouldn’t make any difference.) Thanks for reading! Next: Builder.

I’ll double check with booting from the same boot drive on each some time this week hopefully.

I’ve not done that yet.

• Using ‘bunzip2’, followed by SparkFS to read the Tar files, I have the same (non-filetyped) results for the ‘cvs-repos’ tarball.
  • That’s the riscos.info bunzip2 v. 1.0.5 (10 Dec 2007), which doesn’t improve the situation from v.1.0.4 (20 Dec 2006) as contained within the UnTarBZ2 Tools directory… but then, it was a security fix only.
• And using the same process on ‘src-omap/5/17’, I have the same (correctly filetyped) results.

With the new UnTarBZ2 application, and tarballs from yesterday and today, I’m finding that the I’m finding that UnTarBZ2 stops multi-tasking about 10 minutes into the process. Is this normal, or has it crashed? The mouse cursor still moves, and the Numlock/Capslock/Scrolllock keys are obeyed, but that’s all.

I suspect the latter, because yesterday I got fed up of waiting after a couple of hours or so, and discovered that even Alt-Break and Control-Break did nothing.

UnTarBZ2 has to run with alignment exceptions off, otherwise I get recursion of SIGSEGV or something similar.

Anyway, I’ll leave it on all night, so we’ll be sure to know tomorrow morning!

This morning: “FileCore in use”.

I guess I ought to try downloading UnTarBZ2 again in case the copy I have is corrupted.

I’m finding that UnTarBZ2 stops multi-tasking about 10 minutes into the process.

This morning: “FileCore in use”.

Did you have the hourglass? Could you be experiencing symptoms similar to the ‘WIMP isn’t usable issue’ that I had with SparkPlug? Did you get the MD5 checksum message and is the /tar/bz2 file replaced by a /tar file?

Did you have the hourglass?

No.

Could you be experiencing symptoms similar to the ‘WIMP isn’t usable issue’ that I had with SparkPlug?

The Wimp certainly wasn’t usable. !Alarm’s seconds count didn’t move. Basically the only things that worked were the mouse cursor and the three “lock” keys/LEDs.

Did you get the MD5 checksum message

Yes. The checksum is OK, and it claims to begin the next process.

and is the /tar/bz2 file replaced by a /tar file?

The tar file appears, but I don’t know how complete it is. The /tar/bz2 file doesn’t disappear.

I think it’s caused by too small a system heap (I have 256 kiB normally). Last night I set the UnTarBZ2 operation going on the Iyonix, but with the source and destination files on the BeagleBoard, accessed via Sunfish/Moonfish. Yes, it was dog slow. When I looked this mrning, the BB had an error box up about no more space in the system heap, and when I cleared that, I got FileCore in use. I haven’t had a chance to play again until now, whereupon I saw that the tar file had been created and the tar/bz2 file had gone. Currently the contents of the tar file are being copied (locally on the BB) to the destination directory.

When that’s completed, I’ll try the UnTarBZ2 operation entirely on the BB with a bigger system heap allocation.

Oops, spoke too soon, it’s locked up again.

There seems to be some danger that the BB will complete an UnTarBZ2 operation within the next half hour. There seem to be two minimum steps that must be taken to make UnTarBZ2 work:

1. disable alignment exceptions;
2. increase the system heap allocation.

Why are these steps necessary?

Rats. Spoke too soon again.

Internal error, no stack for trap handler: abort on data transfer at &FC18FC24, pc = 203B2020: registers at 0000FC44

I wanted to try finding where those addresses are, but clearly the BB was so unstable (I kept seeing “FileCore in use” messages at strange places on the screen) that I had to abandon that plan and reboot.

This is with the ROM from 2011-02-28 and the currently available UnTarBZ2 application, but still with a HardDisc4 image from ages ago. Do I need other newer components to make UnTarBZ2 work?

Is it just me who has found it impossible to UnTarBZ2 a source tarball recently? Has anyone else tried?

Has anyone else tried?

Not too recently – will hopefully be able to have a look tonight/tomorrow.

With the new UnTarBZ2 application…

Which one is this? On the ROM image releases page, the self-extracting util file is labelled “2010-10-22” and there’s also a zip file linked to from the ‘Unpacking’ section.

Which one is this? On the ROM image releases page, the self-extracting util file is labelled “2010-10-22” and there’s also a zip file linked to from the ‘Unpacking’ section.

That’s the one.