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
-
Skip pg_baseback long filename test if path too long on Windows
- b94d70a632aa 16.0 landed
- 2e99ce68bcd2 11.21 landed
- 2d3983aea5db 12.16 landed
- 9ebe6fdc5c68 13.12 landed
- fb0f05576a0a 14.9 landed
- c0cb12f9e7b3 15.4 landed
- 1fa25ce70f09 17.0 landed