FW: [CYGWIN] 7.2b3 postmaster doesn't start on Win98

I threw this to cygwin but it doesn't seem to have elisited any
interest over the weekend so I'm sending it here as a beta
problem (not
entirely sure if this is correct or if it should go to bugs).

When trying to start the postmaster on win98se with cygwin
I get told that the data directory must be 0700, but when I
try to chmod to
700, it apparently succeds, but nothing permissions stay at
755. I suspect
this to be because win98 has no real file protection (just a read only
attribute)
(uname -a:
CYGWIN_98-4.10 BX3551 1.3.5(0.47/3/2) 2001-11-13 23:16 i686 unknown)
- Stuart

It works on WinNT, Win2K, ... because full file security is implemented
only in this systems. There could be a dirty hack that disables the
check (for 0700 permissions on $DATADIR) in
src/backend/postmaster/postmaster.c. I don't know if it is possible to
do it during runtime for only Win9x systems.

Dan

=?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz> writes:

When trying to start the postmaster on win98se with cygwin
I get told that the data directory must be 0700, but when I
try to chmod to
700, it apparently succeds, but nothing permissions stay at
755. I suspect
this to be because win98 has no real file protection (just a read only
attribute)

It works on WinNT, Win2K, ... because full file security is implemented
only in this systems. There could be a dirty hack that disables the
check (for 0700 permissions on $DATADIR) in
src/backend/postmaster/postmaster.c. I don't know if it is possible to
do it during runtime for only Win9x systems.

Ugh...

Unless someone can think of a reasonable runtime check to distinguish
win98 from newer systems, I think we have little choice but to make the
data directory permissions check be #ifndef __CYGWIN__. I don't like
this much, but (a) I don't want to hold up 7.2 while we look for better
ideas, and (b) no one should consider a Windoze box secure anyway ;-).

Comments?

regards, tom lane

mlw <markw@mohawksoft.com> writes:

I'll write and test something with cygwin this week if that would help. (If
someone can get to it first it is something stupid like "GetWindowsVersion()"
or something like that.

Well, the non-stupid part is to know which return values correspond to
Windows versions that have proper file permissions and which values to
versions that don't. Given that NT and the other versions are two
separate code streams (no?), I'm not sure that distinguishing this is
trivial, and even less sure that we should assume all future Windows
releases will have it. I'd be more comfortable with an autoconf-like
approach: actually probe the desired feature and see if it works.

I was thinking this morning about trying to chmod the directory and,
if that doesn't report an error, assuming that all is well. On Windows
it'd presumably claim success despite not being able to do what is asked
for. But this would definitely require testing.

I'm really not happy about the idea of holding up the release for this...

regards, tom lane

Tom Lane wrote:

mlw <markw@mohawksoft.com> writes:

I'll write and test something with cygwin this week if that would help. (If
someone can get to it first it is something stupid like "GetWindowsVersion()"
or something like that.

Well, the non-stupid part is to know which return values correspond to
Windows versions that have proper file permissions and which values to
versions that don't. Given that NT and the other versions are two
separate code streams (no?), I'm not sure that distinguishing this is
trivial, and even less sure that we should assume all future Windows
releases will have it. I'd be more comfortable with an autoconf-like
approach: actually probe the desired feature and see if it works.

I was thinking this morning about trying to chmod the directory and,
if that doesn't report an error, assuming that all is well. On Windows
it'd presumably claim success despite not being able to do what is asked
for. But this would definitely require testing.

I'm really not happy about the idea of holding up the release for this...

It is a trivial peice of code to write, there is a bit mask that indicates the
technology. Be it DOS or NT. I will be able to get to it over the week.

The proper test would be to test for "known" DOS legacy because all future
Windows versions will be at least capable of file permissions.

The function call is GetVersionEx(...) it accepts a structure:

Platform SDK: Windows System Information

OSVERSIONINFO

The OSVERSIONINFO data structure contains operating system version
information.
The information includes major and minor version numbers, a build number, a
platform identifier, and descriptive text about the operating system. This
structure is
used with the GetVersionEx function.

typedef struct _OSVERSIONINFO{
DWORD dwOSVersionInfoSize;
DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber;
DWORD dwPlatformId;
TCHAR szCSDVersion[ 128 ];
} OSVERSIONINFO;

Members

dwOSVersionInfoSize
Specifies the size, in bytes, of this data structure. Set this member to
sizeof(OSVERSIONINFO) before calling the GetVersionEx function.
dwMajorVersion
Identifies the major version number of the operating system as follows.
Operating System
Value
Windows 95
4
Windows 98
4
Windows Me
4
Windows NT 3.51
3
Windows NT 4.0
4
Windows 2000
5
Windows XP
5
Windows .NET Server
5

dwMinorVersion
Identifies the minor version number of the operating system as follows.
Operating System
Value
Windows 95
0
Windows 98
10
Windows Me
90
Windows NT 3.51
51
Windows NT 4.0
0
Windows 2000
0
Windows XP
1
Windows .NET Server
1

dwBuildNumber
Windows NT/2000/XP: Identifies the build number of the operating system.

Windows 95/98/Me: Identifies the build number of the operating system in
the
low-order word. The high-order word contains the major and minor version
numbers.
dwPlatformId
Identifies the operating system platform. This member can be one of the
following values.
Value
Platform
VER_PLATFORM_WIN32s
Win32s on Windows 3.1.
VER_PLATFORM_WIN32_WINDOWS
Windows 95, Windows 98, or
Windows Me.
VER_PLATFORM_WIN32_NT
Windows NT 3.51,
Windows NT 4.0,
Windows 2000, Windows XP,
or Windows .NET Server.

szCSDVersion
Windows NT/2000/XP: Contains a null-terminated string, such as "Service
Pack 3", that indicates the latest Service Pack installed on the system.
If no Service
Pack has been installed, the string is empty.

Windows 95/98/Me: Contains a null-terminated string that indicates
additional
version information. For example, " C" indicates Windows 95 OSR2 and " A"
indicates Windows 98 Second Edition.

----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Monday, December 03, 2001 9:52 PM

mlw <markw@mohawksoft.com> writes:

I'll write and test something with cygwin this week if that would help. (If
someone can get to it first it is something stupid like "GetWindowsVersion()"
or something like that.

Well, the non-stupid part is to know which return values correspond to
Windows versions that have proper file permissions and which values to
versions that don't. Given that NT and the other versions are two
separate code streams (no?), I'm not sure that distinguishing this is
trivial, and even less sure that we should assume all future Windows
releases will have it. I'd be more comfortable with an autoconf-like
approach: actually probe the desired feature and see if it works.

I was thinking this morning about trying to chmod the directory and,
if that doesn't report an error, assuming that all is well. On Windows
it'd presumably claim success despite not being able to do what is asked
for. But this would definitely require testing.

I'm really not happy about the idea of holding up the release for this...

Why so much fuss about an officially unsupported platform
at this point in time? Interested individuals can work on a more or less
workable W98 "port" for 7.3 right after the 7.2 release, no?
(They can actually work now, but why this should up the release?)

"Serguei Mokhov" <sa_mokho@alcor.concordia.ca> writes:

Why so much fuss about an officially unsupported platform
at this point in time? Interested individuals can work on a more or less
workable W98 "port" for 7.3 right after the 7.2 release, no?

My point exactly --- let's work on this for 7.3, not 7.2. However,
it'd be nice if 7.2 didn't fail entirely on Win98. Thus the thought
that a simple #ifdef is the right solution for this release.

We did not have any permissions checks in releases before 7.2, so
this approach doesn't mean any regression for newer Windows versions.
It'd be better to have the check in the newer Windows versions, but
I'm satisfied to let that happen in 7.3.

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 03 December 2001 16:05
To: Hor�k Daniel
Cc: pgsql-hackers@postgresql.org; Peter Eisentraut
Subject: Re: FW: [CYGWIN] 7.2b3 postmaster doesn't start on Win98

=?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz> writes:

When trying to start the postmaster on win98se with cygwin
I get told that the data directory must be 0700, but when I
try to chmod to
700, it apparently succeds, but nothing permissions stay at
755. I suspect
this to be because win98 has no real file protection (just

a read only

attribute)

It works on WinNT, Win2K, ... because full file security is
implemented only in this systems. There could be a dirty hack that
disables the check (for 0700 permissions on $DATADIR) in
src/backend/postmaster/postmaster.c. I don't know if it is

possible

to do it during runtime for only Win9x systems.

Ugh...

Unless someone can think of a reasonable runtime check to
distinguish win98 from newer systems, I think we have little
choice but to make the data directory permissions check be
#ifndef __CYGWIN__. I don't like this much, but (a) I don't
want to hold up 7.2 while we look for better ideas, and (b)
no one should consider a Windoze box secure anyway ;-).

This check actually caused me *much* grief when I was testing on Win2K/XP.
It required that the cygwin ntsec option is enabled which in my case caused
me even more problems with my Cygwin installation. I vote for the #ifndef
__CYGWIN__...

Regards, Dave.

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 04 December 2001 02:53
To: mlw
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: FW: [CYGWIN] 7.2b3 postmaster doesn't start on Win98

mlw <markw@mohawksoft.com> writes:

I'll write and test something with cygwin this week if that would
help. (If someone can get to it first it is something stupid like
"GetWindowsVersion()" or something like that.

Well, the non-stupid part is to know which return values
correspond to Windows versions that have proper file
permissions and which values to versions that don't. Given
that NT and the other versions are two separate code streams
(no?), I'm not sure that distinguishing this is trivial, and
even less sure that we should assume all future Windows
releases will have it. I'd be more comfortable with an autoconf-like
approach: actually probe the desired feature and see if it works.

I was thinking this morning about trying to chmod the
directory and, if that doesn't report an error, assuming that
all is well. On Windows it'd presumably claim success
despite not being able to do what is asked for. But this
would definitely require testing.

It does (at least on my systems).

/Dave

Dave Page wrote:

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 04 December 2001 02:53
To: mlw
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: FW: [CYGWIN] 7.2b3 postmaster doesn't start on Win98

mlw <markw@mohawksoft.com> writes:

I'll write and test something with cygwin this week if that would
help. (If someone can get to it first it is something stupid like
"GetWindowsVersion()" or something like that.

Well, the non-stupid part is to know which return values
correspond to Windows versions that have proper file
permissions and which values to versions that don't.

IIRC, it depends also on filesystem, i.e. FAT32 on NT/2000 dos still
not have proper permissions.

Given
that NT and the other versions are two separate code streams
(no?), I'm not sure that distinguishing this is trivial, and
even less sure that we should assume all future Windows
releases will have it. I'd be more comfortable with an autoconf-like
approach: actually probe the desired feature and see if it works.

I was thinking this morning about trying to chmod the
directory and, if that doesn't report an error, assuming that
all is well. On Windows it'd presumably claim success
despite not being able to do what is asked for. But this
would definitely require testing.

It does (at least on my systems).

It does what ? Report an error, claim success or need testing ?

--------------
Hannu

Tom Lane wrote:

=?iso-8859-1?Q?Hor=E1k_Daniel?= <horak@sit.plzen-city.cz> writes:

When trying to start the postmaster on win98se with cygwin
I get told that the data directory must be 0700, but when I
try to chmod to
700, it apparently succeds, but nothing permissions stay at
755. I suspect
this to be because win98 has no real file protection (just a read only
attribute)

It works on WinNT, Win2K, ... because full file security is implemented
only in this systems. There could be a dirty hack that disables the
check (for 0700 permissions on $DATADIR) in
src/backend/postmaster/postmaster.c. I don't know if it is possible to
do it during runtime for only Win9x systems.

Ugh...

Unless someone can think of a reasonable runtime check to distinguish
win98 from newer systems, I think we have little choice but to make the
data directory permissions check be #ifndef __CYGWIN__. I don't like
this much, but (a) I don't want to hold up 7.2 while we look for better
ideas, and (b) no one should consider a Windoze box secure anyway ;-).

Comments?

I have an idea which my side step the whole question about Windows.

Why not have a postgres option which allows the admin to specify that Postgres
does not check file permissions? Then it becomes a documentation issue.

Dave Page <dpage@vale-housing.co.uk> writes:

Unless someone can think of a reasonable runtime check to
distinguish win98 from newer systems, I think we have little
choice but to make the data directory permissions check be
#ifndef __CYGWIN__. I don't like this much, but (a) I don't
want to hold up 7.2 while we look for better ideas, and (b)
no one should consider a Windoze box secure anyway ;-).

This check actually caused me *much* grief when I was testing on Win2K/XP.
It required that the cygwin ntsec option is enabled which in my case caused
me even more problems with my Cygwin installation. I vote for the #ifndef
__CYGWIN__...

Oh, so it's (in essence) an optional feature on Cygwin? And someone
else pointed out that it depends on the filesystem in use, too.

Okay, I think the answer is clear: #ifndef __CYGWIN__ for 7.2. We can
think about nicer approaches for 7.3.

I'll apply the change shortly.

regards, tom lane

Tom Lane writes:

Unless someone can think of a reasonable runtime check to distinguish
win98 from newer systems, I think we have little choice but to make the
data directory permissions check be #ifndef __CYGWIN__.

I don't think so. We've never claimed to support Cygwin on Windows
95/98/ME, but we've reasonably supported Cygwin on Windows NT/2000 and we
shouldn't break that to support some other system.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

Unless someone can think of a reasonable runtime check to distinguish
win98 from newer systems, I think we have little choice but to make the
data directory permissions check be #ifndef __CYGWIN__.

I don't think so. We've never claimed to support Cygwin on Windows
95/98/ME, but we've reasonably supported Cygwin on Windows NT/2000 and we
shouldn't break that to support some other system.

Not applying a data directory permissions check doesn't quite rise to
the level of "breaking it", I think, unless you want to argue that 7.1
and before were all broken because they didn't have the check. Note
also Dave Page's complaint about ntsec, and the observation that
availability of Unixy file permissions depends on the filesystem type
even under more recent Windowsen. So we've got some issues here even
on the recent ones.

It's my feeling that the better part of engineering judgment is to
disable the check for the moment. It seems too risky to leave it in,
and I don't want to postpone the release while we think of a better
answer.

regards, tom lane

Tom Lane writes:

We did not have any permissions checks in releases before 7.2, so
this approach doesn't mean any regression for newer Windows versions.

We did have the same permission check in 7.1, only it was on
$PGDATA/postgresql.conf instead. Nothing has changed materially.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

We did not have any permissions checks in releases before 7.2, so
this approach doesn't mean any regression for newer Windows versions.

We did have the same permission check in 7.1, only it was on
$PGDATA/postgresql.conf instead. Nothing has changed materially.

Hmmm ... why weren't Windows users complaining before, then?

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Tom Lane writes:

We did not have any permissions checks in releases before 7.2, so
this approach doesn't mean any regression for newer Windows versions.

We did have the same permission check in 7.1, only it was on
$PGDATA/postgresql.conf instead. Nothing has changed materially.

Hmmm ... why weren't Windows users complaining before, then?

It was not the same permission check.
The check allowed 0744 whereas the current check only allows
0700.

regards,
Hiroshi Inoue