Description of problem:
The tar program uses a built-in table of magic numbers to identify compressed archives. If the table fails to match a given file then tar will still attempt to open it by assuming the compression type based on file extension:

 219 static struct zip_magic const magic[] = {
 220   { ct_tar },
 221   { ct_none, },
 222   { ct_compress, 2, "\037\235",  COMPRESS_PROGRAM, "-Z" },
 223   { ct_gzip,     2, "\037\213",  GZIP_PROGRAM,     "-z"  },
 224   { ct_bzip2,    3, "BZh",       BZIP2_PROGRAM,    "-j" },
 225   { ct_lzip,     4, "LZIP",      LZIP_PROGRAM,     "--lzip" },
 226   { ct_lzma,     6, "\xFFLZMA",  LZMA_PROGRAM,     "--lzma" },
 227   { ct_lzop,     4, "\211LZO",   LZOP_PROGRAM,     "--lzop" },
 228   { ct_xz,       6, "\0xFD7zXZ", XZ_PROGRAM,       "-J" },
 229 };
[...]
 324             case ct_none:
 325               if (shortfile)
 326                 ERROR ((0, 0, _("This does not look like a tar archive")));
 327               set_comression_program_by_suffix (archive_name_array[0], NULL);
 328               if (!use_compress_program_option)
 329                 return archive;
 330               break;

An exception is for "short" files; in this case an error message is logged and tar will eventually exit with failure status:

# tar tf foo.tar.xz 
tar: This does not look like a tar archive
foo/
foo/bar
tar: Exiting with failure status due to previous errors
# echo $?
2

This is misleading as tar has guessed the compression type and successfully processed the archive.

Version-Release number of selected component (if applicable):
tar-1.23-11.el6

How reproducible:
100%

Steps to Reproduce:
1. Create an xz compressed archive that is < 1 block in size
2. Run tar on the resulting archive (t/x/whatever)

Actual results:
# rm -rf foo
# mkdir foo
# touch foo/bar
# tar cf foo.tar foo
# xz foo.tar
# tar tf foo.tar.xz 
tar: This does not look like a tar archive
foo/
foo/bar
tar: Exiting with failure status due to previous errors
# echo $?
2


Expected results:
# rm -rf foo
# mkdir foo
# touch foo/bar
# tar cf foo.tar foo
# xz foo.tar
# tar tf foo.tar.xz 
foo/
foo/bar
# echo $?
0


Additional info:
This happens because tar uses an invalid magic number for XZ files in its magic table:

 228   { ct_xz,       6, "\0xFD7zXZ", XZ_PROGRAM,       "-J" },

The correct magic string for XZ is "fd37 7a58 5a" (\xfd7zXZ). The '\0' encodes a null byte causing the rest of the magic string to appear empty:

(gdb) p *p                               -----------
$38 = {type = ct_xz, length = 6, magic = 0x445e20 "", program = 0x44596a "xz", rpl_option = 0x44596d "-J"}

'FD' is then encoded as ASCII etc.

It seems like the intent was to avoid gcc treating '\xfd7' as a single hex escape this will cause a "hex escape sequence out of range" warning as the 7 is interpreted as part of the escape.

It seems like the simplest way to solve this is to also use a hex escape for the '7' char; this leaves the string unambiguous and fixes the problem with very small tar archives for me:

  { ct_xz,       6, "\xFD\x37zXZ", XZ_PROGRAM,       "-J" },