| 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: | Whole Thread | Raw Message | 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 |