Pg_upgrade writes temporary files (e.g. _dumpall output) into the
current directory, rather than a temporary directory or the user's home
directory. (This was decided by community discussion.)
I have a check in pg_upgrade 9.1 to make sure pg_upgrade has write
permission in the current directory:
if (access(".", R_OK | W_OK
#ifndef WIN32
/*
* Do a directory execute check only on Unix because execute
permission on
* NTFS means "can execute scripts", which we don't care about.
Also, X_OK
* is not defined in the Windows API.
*/
| X_OK
#endif
) != 0)
pg_log(PG_FATAL,
"You must have read and write access in the current
directory.\n");
Unfortunately, I have received a bug report from EnterpriseDB testing
that this does not trigger the FATAL exit on Windows even if the user
does not have write permission in the current directory, e.g. C:\.
I think I see the cause of the problem. access() on Windows is
described here:
http://msdn.microsoft.com/en-us/library/1w06ktdy%28v=vs.80%29.aspx
It specifically says:
When used with directories, _access determines only whether the
specified directory exists; in Windows NT 4.0 and Windows 2000, all
directories have read and write access.
...
This function only checks whether the file and directory are read-only
or not, it does not check the filesystem security settings. For
that you need an access token.
We do use access() in a few other places in our code, but not for
directory permission checks.
Any ideas on a solution? Will checking stat() work? Do I have to try
creating a dummy file and delete it?
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
