Re: Patch: incorrect array offset in backend replication tar header - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Patch: incorrect array offset in backend replication tar header
Date
Msg-id 2162.1348540592@sss.pgh.pa.us
Whole thread Raw
In response to Re: Patch: incorrect array offset in backend replication tar header  (Brian Weaver <cmdrclueless@gmail.com>)
Responses Re: Patch: incorrect array offset in backend replication tar header  (Brian Weaver <cmdrclueless@gmail.com>)
List pgsql-hackers
Brian Weaver <cmdrclueless@gmail.com> writes:
> Here are lines 321 through 329 of 'archive_read_support_format_tar.c'
> from libarchive

>  321         /* Recognize POSIX formats. */
>  322         if ((memcmp(header->magic, "ustar\0", 6) == 0)
>  323             && (memcmp(header->version, "00", 2) == 0))
>  324                 bid += 56;
>  325
>  326         /* Recognize GNU tar format. */
>  327         if ((memcmp(header->magic, "ustar ", 6) == 0)
>  328             && (memcmp(header->version, " \0", 2) == 0))
>  329                 bid += 56;

> I'm wondering if the original committer put the 'ustar00\0' string in by design?

The second part of that looks to me like it matches "ustar  \0",
not "ustar00\0".  I think the pg_dump coding is just wrong.  I've
already noticed that its code for writing the checksum is pretty
brain-dead too :-(

Note that according to the wikipedia page, tar programs typically
accept files as pre-POSIX format if the checksum is okay, regardless of
what is in the magic field; and the fields that were added by POSIX
are noncritical so we'd likely never notice that they were being
ignored.  (In fact, looking closer, pg_dump isn't even filling those
fields anyway, so the fact that it's not producing a compliant magic
field may be a good thing ...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Karl O. Pinc"
Date:
Subject: Re: Doc patch to note which system catalogs have oids
Next
From: Michael Paquier
Date:
Subject: Re: pg_reorg in core?