From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: readdir is incorrectly implemented at Windows |
Date: | 2019-03-01 17:36:55 |
Message-ID: | 7b740522-3c48-1217-03f0-e2acf8f6b345@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/25/19 10:38 AM, Konstantin Knizhnik wrote:
> Hi hackers,
>
> Small issue with readir implementation for Windows.
> Right now it returns ENOENT in case of any error returned by
> FindFirstFile.
> So all places in Postgres where opendir/listdir are used will assume
> that directory is empty and
> do nothing without reporting any error.
> It is not so good if directory is actually not empty but there are not
> enough permissions for accessing the directory and FindFirstFile
> returns ERROR_ACCESS_DENIED:
>
> struct dirent *
> readdir(DIR *d)
> {
> WIN32_FIND_DATA fd;
>
> if (d->handle == INVALID_HANDLE_VALUE)
> {
> d->handle = FindFirstFile(d->dirname, &fd);
> if (d->handle == INVALID_HANDLE_VALUE)
> {
> errno = ENOENT;
> return NULL;
> }
> }
>
>
> Attached please find small patch fixing the problem.
>
Diagnosis seems correct. I wonder if this is responsible for some odd
things we've seen over time on Windows.
This reads a bit oddly:
{
- errno = ENOENT;
+ if (GetLastError() == ERROR_FILE_NOT_FOUND)
+ {
+ /* No more files, force errno=0 (unlike mingw) */
+ errno = 0;
+ return NULL;
+ }
+ _dosmaperr(GetLastError());
return NULL;
}
Why not something like:
if (GetLastError() == ERROR_FILE_NOT_FOUND)
errno = 0;
else
_dosmaperr(GetLastError());
return NULL;
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-03-01 17:42:56 | Re: Refactoring the checkpointer's fsync request queue |
Previous Message | Nikita Glukhov | 2019-03-01 17:03:36 | Re: SQL/JSON: JSON_TABLE |