Use of access(X_OK) check in pg_upgrade
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:
if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, May 18, 2011 at 11:41, Bruce Momjian <bruce@momjian.us> wrote:
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
It doesn't natively - we define it in port/win32.h
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Bruce Momjian wrote:
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
I have applied the attached patch to fix this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
/rtmp/pg_upgradetext/x-diffDownload
diff --git a/contrib/pg_upgrade/exec.c b/contrib/pg_upgrade/exec.c
new file mode 100644
index 6f1c6ef..ec2f944
*** a/contrib/pg_upgrade/exec.c
--- b/contrib/pg_upgrade/exec.c
*************** void
*** 94,100 ****
verify_directories(void)
{
! if (access(".", R_OK | W_OK | X_OK) != 0)
pg_log(PG_FATAL,
"You must have read and write access in the current directory.\n");
--- 94,109 ----
verify_directories(void)
{
! if (access(".", R_OK | W_OK
! #ifndef WIN32
! /*
! * Directory execute permission on NTFS means "can execute scripts",
! * which we don't care about, so skip the check. Also, X_OK is not
! * defined in the API.
! */
! | X_OK
! #endif
! ) != 0)
pg_log(PG_FATAL,
"You must have read and write access in the current directory.\n");
Magnus Hagander wrote:
On Wed, May 18, 2011 at 11:41, Bruce Momjian <bruce@momjian.us> wrote:
I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:? ? ? ? ? ?if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
It doesn't natively - we define it in port/win32.h
Sure, but that is defined as _S_IEXEC:
#define S_IXUSR _S_IEXEC
#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
So what is _S_IEXEC. Anyway, execute permission means something
different on Win32 for directories so I have a fix applied.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On Wed, May 18, 2011 at 12:16, Bruce Momjian <bruce@momjian.us> wrote:
Magnus Hagander wrote:
On Wed, May 18, 2011 at 11:41, Bruce Momjian <bruce@momjian.us> wrote:
I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:? ? ? ? ? ?if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
It doesn't natively - we define it in port/win32.h
Sure, but that is defined as _S_IEXEC:
#define S_IXUSR _S_IEXEC
#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)So what is _S_IEXEC. Anyway, execute permission means something
different on Win32 for directories so I have a fix applied.
I'm pretty sure it's mapped to read permissions internally in the API headers.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/