On 07/23/2011 08:45 AM, Bruce Momjian wrote:
> 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?
That looks like the obvious solution - it's what came to my mind even
before reading this sentence.
cheers
andrew
