detecting end of tar archive

[NickJohnson]

Because I don't want to write and debug my own format, I've been using a standard tar generated archive for my initrd. I need to access the initrd at multiple points, including after the kernel has booted. When the kernel accesses it, it also has information from GRUB about the size of the archive, so it knows how not to fall off the end. But now I have to do accesses to the initrd from init in usermode. I know from the tar documentation that the end of the archive is marked by two completely null 512 byte blocks. However, there are sections of some of the binaries in the archive that are null for more than 1024 bytes (e.g. the initial static page directory), so init thinks the archive ends there and is unable to find all of the data. If I look for more empty space than 1024 bytes, I run off the end and get a page fault. How do I properly detect the end of the archive?

My current solution is to add an extra 4096 bytes of null characters to the end of the archive and check for that, but it's sort of a hack, and it wouldn't be obvious why it is done a user trying to rebuild the initrd.

[JamesM]

Hi,

The TAR format is massively simple, just follow the chain of files until you find a descriptor with filename length zero. Voila.

[NickJohnson]

Hmm... looking up the tar docs again, I can't find where it says that there are two null blocks at the end of the archive - furthermore, it makes absolutely no sense that things would work that way. I guess I must have confused it with something else. I'm probably going to just add a block before the initrd when I copy it to usermode that lists the size - it's easier/faster than searching the archive, because I already have that information. I'm assuming that the way it works fine under *nix is that it just detects an EOF (at the end of the file, of course ).

[NickJohnson]

Yes, but when was the last time TAR was actually used with a physical tape drive? I'm just saying that nowadays it's probably done with an EOF, which is easier than actually parsing anything. It also seems like an OS managing a tape drive would be able to generate an EOF, if it knows the the dimensions of the tape.

[yemista]

Well EOF is just a number, but Im pretty sure tar hasnt changed since the days of tapes, cuz you can still use tape drives under linux if you want, its just that no one does. Tar is just a sequence of files made into one file. I never looked at the spec myself, but if each file has a header block in front of it, why wouldnt it work by having two blocks that say their file length is 0 at the end of the chain? You can also have some magic number in the header block, and have the last one be some special value that tells you you are at the end.

[Brynet-Inc]

Well EOF is just a number, but Im pretty sure tar hasnt changed since the days of tapes, cuz you can still use tape drives under linux if you want, its just that no one does.

Really? nobody at all? how odd.

[Love4Boobies]

you can still use tape drives under linux if you want, its just that no one does.

You mean home users (usually) don't. Tape drives are still used in backup pretty much these days.