bug-tar
[Top][All Lists]
Advanced

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

[Bug-tar] bug in pax_dump_header_1()?


From: Bernd Schubert
Subject: [Bug-tar] bug in pax_dump_header_1()?
Date: Wed, 24 Nov 2010 01:57:49 +0100
User-agent: KMail/1.13.5 (Linux/2.6.36-1-generic; KDE/4.5.1; x86_64; ; )

Hello all,

I'm not sure, but I think there is a generic bug in pax_dump_header_1(). 
However, the only way to trigger that seems to include the patches from RedHat 
patched tar versions to add --xattr support. As we (DDN) usually use tar to 
create backups of Lustre MDTs (meta data targets), we do need xattr support, 
or we would have to run another rather slow instance of 'getfattr'.

Problem description:
- on extracting archives created with the patched tar version, the resulting 
directory structures has LOTs of GNUSparseFile.*, such as

mdt/ROOT/tmp/frederik/build/lustre-1.6.7.2.ddn3.5/libsysio/src/.deps/GNUSparseFile.1439064
mdt/ROOT/tmp/frederik/build/lustre-1.6.7.2.ddn3.5/libsysio/tests/GNUSparseFile.1439064
mdt/ROOT/tmp/frederik/build/lustre-1.6.7.2.ddn3.5/libsysio/tests/.deps/GNUSparseFile.1439064

Real files are missing instead. Tar did *NEITHER* complain about errors when 
the archive was created *NOR* did it on extracting the archive. So *silent* 
data corruption!

So what makes me think the bug is is in pax_dump_header_1() and not in the 
xattr() patch from RedHat:

- The xattr patch modifies start_header(), which is called by 
pax_dump_header_1()
- The problem does *NOT* come up with "--sparse-version=0.0"
- Lets compare dump_regular_file() and pax_dump_header_1():
  - both do call blk = start_header() and finish_header()
  - dump_regular_file carefully checkes for blk == 0
  - pax_dump_header_1 and also pax_dump_header_0 forget to check for blk == 0
    --> possible  NULL pointer dereference
  - both call blk = find_next_block ();
  - dump_regular_file carefully checks for 
     bufsize = available_space_after (blk);
    and does not write more than bufsize
  - pax_dump_header_1 does *NOT* have such a test, and I *guess* that is the 
problem. I don't know yet why, but if somehow the data do not seem to fit into 
the block anymore with xattr.

I did not file a RedHat bug yet, as it seems to be more a bug rather in sparse 
file handling than with xattr support.


Cheers,
Bernd

-- 
Bernd Schubert
DataDirect Networks



reply via email to

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