Thread: FW: [CYGWIN] 7.2b3 postmaster doesn't start on Win98
Hi,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). - Stuart -----Original Message----- From: Henshall, Stuart - WCP [mailto:SHenshall@westcountrypublications.co.uk] Sent: 30 November 2001 19:13 To: 'pgsql-cygwin@postgresql.org' Subject: [CYGWIN] 7.2b3 postmaster doesn't start on Win98 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
> 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
Horák 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
descriptivetext about the operating system. This
structure is used with the GetVersionEx function.
typedef struct _OSVERSIONINFO{ DWORD dwOSVersionInfoSize; DWORD dwMajorVersion; DWORD dwMinorVersion;
DWORDdwBuildNumber; 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
ofthe 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
Identifiesthe operating system platform. This member can be one of the following values. Value
Platform VER_PLATFORM_WIN32s Win32s on
Windows3.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
thelatest 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
SecondEdition.
----- 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: 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
> -----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 > > > Horák 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.
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: > > Horák 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
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 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
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