From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Hillary Masha <hillarymasha(at)geotab(dot)com> |
Cc: | Thomas Kellerer <shammat(at)gmx(dot)net>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Corrupted Postgresql Microsoft Binaries |
Date: | 2022-08-29 15:09:12 |
Message-ID: | 09fceda4-ff63-2c3c-1e3b-fed14274e06e@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 8/29/22 07:50, Hillary Masha wrote:
> After further investigation, it was determined that the issue was with
> the length of the path of some subdirectories in the zip file for the
> new binaries. Windows has a max path length of 260 characters, hence the
> issue with unzipping.
> Postgres V 14.3 had a max file path length of 226
> image.png
> Postgres V 14.5 has a max file path length of 321
> image.png
>
> My team uses powershell v5 in our code to unzip these files, we needed
> to enable 'Long Path' for the files to be successfully unzipped. This
Hmm, this must be a MS client software fix as non-MS products don't have
this issue when unzipping. I see the long directory in the archive
unzipped by 7-zip.
> was added as an opt-in by Microsoft for Windows 10
> (https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell
> <https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell>).
> Note that the files were successfully unzipped in Powershell v7 without
> making any changes.
>
> On Wed, Aug 24, 2022 at 5:36 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Meera Nair | 2022-08-30 05:22:56 | RE: Unable to archive logs in standby server |
Previous Message | Hillary Masha | 2022-08-29 14:50:35 | Re: Corrupted Postgresql Microsoft Binaries |