From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brian Weaver <cmdrclueless(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: incorrect array offset in backend replication tar header |
Date: | 2012-09-25 02:36:32 |
Message-ID: | 2162.1348540592@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brian Weaver <cmdrclueless(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2012-09-25 02:37:05 | Re: pg_reorg in core? |
Previous Message | Karl O. Pinc | 2012-09-25 02:32:14 | Re: Doc patch to note which system catalogs have oids |