Re: pg_basebackup check vs Windows file path limits

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Alexander Lakhin <exclusion@gmail.com>, Daniel Gustafsson <daniel@yesql.se>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-11-12T14:09:27Z
Lists: pgsql-hackers
On 2023-11-11 Sa 12:00, Alexander Lakhin wrote:
> 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.)
>
>

*sigh*

A probable workaround is to use a temp directory on the same device the 
test is building on. Just set it up and set your environment TEMPDIR to 
point to it, and I think it will be OK (i.e. I havent tested it).

But that doesn't mean I'm not searching for a better solution. Maybe 
Alvaro's suggestion nearby will help.


cheers


andrew


--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Commits

  1. Skip pg_baseback long filename test if path too long on Windows