From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup check vs Windows file path limits |
Date: | 2023-11-11 17:00:01 |
Message-ID: | 6aa7c5a0-a4c8-dd2c-3a99-946eb7f23155@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
11.11.2023 18:18, Andrew Dunstan wrote:
>
> Hmm, maybe we should be using File::Copy::move() instead of rename(). The docco for that says:
>
> If possible, move() will simply rename the file. Otherwise, it
> copies the file to the new location and deletes the original. If an
> error occurs during this copy-and-delete process, you may be left
> with a (possibly partial) copy of the file under the destination
> name.
Unfortunately, I've stumbled upon inability of File::Copy::move()
to move directories across filesystems, exactly as described here:
https://stackoverflow.com/questions/17628039/filecopy-move-directories-accross-drives-in-windows-not-working
(I'm sorry for not looking above rename() where this stated explicitly:
# On Windows use the short location to avoid path length issues.
# Elsewhere use $tempdir to avoid file system boundary issues with moving.
So this issue affects Windows only.)
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | Vladimir Churyukin | 2023-11-11 17:03:48 | Re: Making auto_explain more useful / convenient |
Previous Message | Alvaro Herrera | 2023-11-11 16:31:39 | Re: pg_basebackup check vs Windows file path limits |