| 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: | Whole Thread | Raw Message | 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 |