Re: Error on compile for Windows - Mailing list pgsql-general

From Steve Atkins
Subject Re: Error on compile for Windows
Date
Msg-id 0F293208-3ADF-4EE5-B61D-235BA714B94A@blighty.com
Whole thread Raw
In response to Re: Error on compile for Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Renaming conversion procs (was Re: Error on compile for Windows)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Nov 1, 2009, at 10:19 PM, Tom Lane wrote:

> Craig Ringer <craig@postnewspapers.com.au> writes:
>> On 2/11/2009 11:40 AM, Tom Lane wrote:
>>> src/backend/utils/mb/conversion_procs/
>>> euc_jis_2004_and_shift_jis_2004/euc_jis_2004_and_shift_jis_2004.c
>>> We have seen reports of certain versions of "tar" failing to extract
>>> this file from the source tarball, probably because its name is so
>>> long.  That could have happened to you --- if so, the recommendation
>>> is to find another tool to un-tar with.
>
>> I almost wonder if a `configure' test to detect this particular
>> form of
>> source tree corruption would be helpful.
>
> If we were going to expend any effort on this problem, my vote would
> be
> to rename the file to something less carpal-tunnel-promoting.  There's
> no real reason it couldn't be euc2004_and_sjis2004.c or some such.
>
> The problem with doing anything is that we have only a couple of
> reports
> and so no solid picture of what the restriction is.

I've seen this problem with tar on most versions of Solaris. While the
documented limits are 255 characters, with a limit of 100 characters
on the basename there are times when if the tarball is created with
gnutar the Solaris tar seems to fail to extract pathnames longer than
100
characters.

I've also seen it with winzip. Again, ISTR that the exact limits were
obscure
but that restricting the path to less than 100 characters avoided any
problems.

This case is 105 characters long, so wouldn't be hard to pull below
that threshold.

Cheers,
   Steve


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Cancelling Requests Frontend/Backend Protocol TCP/IP
Next
From: Raimon Fernandez
Date:
Subject: Re: Cancelling Requests Frontend/Backend Protocol TCP/IP