On 2026-04-01 We 8:16 PM, Thomas Munro wrote:
On Thu, Apr 2, 2026 at 7:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Also, if we are admitting the possibility that what we are reading
was made by a platform-supplied tar and not our own code, I think
it verges on lunacy to behave as though unsupported typeflags are
regular files.
Yeah, if this is the first time we parse files we didn't make then
that makes total sense. I was a bit unsure of that question when I
suggested we reject pax only after we've failed to find a file, in
case there are scenarios that work today with harmless ignorable pax
headers that don't change the file name.
So I think we need something more or less like the attached.
LGTM. Tested with both tars here. I updated that little test patch
for this. Not sure if you think it's worth a test though, now that
it's so simple.
@Andrew: I tried using File::Spec->devnull() this time. Are you able
to check if this works OK on Windows, applied on top of Tom's patch?
AFAIK should be able to run this new test and pass, not skip it. But
it could be that the shell invocation needs tweaking. It's hard to
tell from CI. (Huh, apparently Windows ships a copy of BSD tar as
C:\Windows\System32\tar.exe these days.)
Yes, that appears to work. I would put a "2>&1" at the end - we don't care about the output, just whether or not it succeeds:
C:\Windows\system32>perl -MFile::Spec -e "print File::Spec->devnull();"
nul
C:\Windows\system32>tar --no-read-sparse -c - nul > nul 2>&1 && echo hello
C:\Windows\system32>tar --no-read-sparse -c - nul > nul 2>&1 || echo hello
hello
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
