bug-tar
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-tar] format v7 unexpected header fields


From: Mario Aichinger
Subject: [Bug-tar] format v7 unexpected header fields
Date: Wed, 11 Nov 2015 20:16:18 +0100

Hi tar community!

Tar version:

# tar --version
tar (GNU tar) 1.28
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.

Linux version:

uname -a
Linux monster 4.2.3-1-ARCH #1 SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 GNU/Linux


You can skip the next section it is just a bit of an intro.

Last week I did a research about the v7 format. I did this, because I wanted to push my programming skills and thought, why not to program a tar extractor. So I started reading about the most basic tar format which is obviously v7. The first thing I programed was the part which tries to find out which version of archive is passed to my program (v7, star, ustar, gnu, posix, pax, ...). My understanding was and is that v7 tar's have a 256 byte padding (null bytes) at the end of their headers, and an empty  magic header field. So these are the things I test against. After I implemented this in my program I created some test archives. Of course with tar and the option --format=v7. But my program failed to detect them as v7 tar's. So I opened them (the archives) in a text editor (kate) and found two fields in the header filled with zeros. This fields where located after the linkname header field.

When I create archives with tar and the --format=v7 option the archive has two zero filled fields in the header at a location of the posix-ustar-devmajor-field and the posix-ustar-devminor-field. If I understand the format correctly and v7 is referring to the format I'm thinking of there should only be a null byte filled padding of 256 byte length.

The format im referring to is this format:

{
   char name[100];
   char mode[8];
   char uid[8];
   char gid[8];
   char size[12];
   char mtime[12];
   char checksum[8];
   char linkflag[1];
   char linkname[100];
   char pad[255];
};

(from: https://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5)

There is a file attached which shows the problematic fields (colored in red)

Another thing why I think that this is a bug, is that the bsdtar (libarchive) implementation does not add these fields. Also the gnu documentation mentions that the v7 format does not have the capability to store device numbers (the fields are exactly at the position where a posix-ustar archive would store devmajor and devminor). See v7 limitations at https://www.gnu.org/software/tar/manual/html_section/tar_68.html

Steps to reproduce the archive:

1. # cd /tmp
2. # mkdir testtar && cd testtar
3. # echo "this is a test" > test.txt
4. # tar --format=v7 -cvf test.tar test.txt 
5. # cat test.tar | less


Best wishes from Vienna - Mario

Attachment: tar_raw_colored.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]