On Thu, Nov 21, 2019 at 3:35 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote:
> > On 11/20/19 3:40 PM, Thomas Munro wrote: > > On Fri, Nov 8, 2019 at 3:41 AM Andrew Dunstan > > <andrew.duns...@2ndquadrant.com> wrote: > >> On 11/7/19 9:12 AM, Alvaro Herrera wrote: > >>>> The patch says: > >>>> > >>>> + require Win32::API; > >>>> + Win32::API->import; > >>> Oh, you're right, it does. I wonder why, though: > >>> > >> On further inspection I think those lines are unnecessary. The remainder > >> of the patch doesn't use this at all, AFAICT. > > So does that mean we're back on, we can use a patch like Juan Jose's? > > I'd love to get rid of these intermittent buildfarm failures, like > > this one just now: > > > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2019-11-20%2010%3A00%3A10 > > > > Here you can see: > > > > could not read > "C:/prog/bf/root/HEAD/pgsql.build/src/bin/pg_ctl/tmp_check/t_004_logrotate_primary_data/pgdata/current_logfiles": > > Permission denied at > > C:/prog/bf/root/HEAD/pgsql.build/src/test/perl/TestLib.pm line 397. > > > > That line is in the subroutine slurp_file, and says open(my $in, '<', > > $filename). Using various clues from this thread, it seems like we > > could, on Windows only, add code to TestLib.pm's INIT to rebind > > *CORE::GLOBAL::open to a wrapper function that would just do > > CreateFile(..., PLEASE_BE_MORE_LIKE_UNIX, ...). > > > Possibly. I will do some testing on drongo in the next week or so. > > I think Perl's open() is a bad candidate for an overload, so I will update the previous patch that only touches slurp_file(). This version address the issues with the required libraries and uses functions that expose less of the Windows API. Regards, Juan José Santamaría Flecha
0001-tap-file_share-windows-file-access-v2.patch
Description: Binary data