Re: initdb failure with PostgreSQL 7.3.2 / Cygwin 1.3.22-1 /

More info:

* Reset everything to the way things 'normally' would be (user
   'postgres' only a member of 'Users', ipc-daemon configured to run as
   Local System account, etc.).
* Logged in as 'Frank' (aka, admin acct), made sure /tmp/MultiFile* was
   removed, then did 'net start ipc-daemon' to bring IPC up.
* Made sure /tmp/MultiFile* files were there and world read/writable.
* ran 'ipctest s' and successfully created semaphore 0.  Did a few more
   and all worked.
* Switched out and logged in as 'postgres', brought up BASH, and tried
   'ipctest s', and failed as usual.
* Did a 'ps' and saw only the shell and the ps command...no ipc-daemon.
* For fun, tried 'ipc-daemon &', and it fired up!
* Ran 'ps' again and confirmed that ipc-daemon was now listed.
* Ran 'ipctest s' now, and it worked!

Interesting thing to note, though, is that the command created semaphore 
0 all over again.  It's as if the copy of ipc-daemon running in the 
'postgres' context is oblivious to the copy running as Local System 
account.  It created a semaphore with the same index number (normally it 
seems to increment by 1 each time, and if you do 'ipck all' to kill off 
all the semaphores, the next one you create is like 4-500 higher in 
number...doesn't continue the sequence in order).

	When I kill postgres' ipc-daemon, close BASH, log out, and switch back 
to user 'Frank' and do 'ipctest s', that works as well.  Obviously as 
'Frank' I'm accessing the service copy of ipc-daemon.

	Now here are a few other items floating around in my noggin.  I do know 
for a fact that Microsoft has changed the file permission settings for 
the root level of their drives between Windows 2000 and Windows XP. 
That is, when I did base installs of Win2K and WinXP, I found that the 
permissions on C:\, D:\, etc., were much tighter under XP than they were 
under Win2K.  I didn't do a full comparative analysis, but let's just 
say I ran into some interesting permission issues thanks to that in the 
past.  Whereas the default in Win2K is something along the order of 
Everyone has full rights (and then the install closes down those rights 
for \WINNT, etc.), in WinXP the root level is much tighter, and it is 
inherited down the tree.  This required my overriding the permissions at 
the root level on data partitions of some systems in order to make 
Windows version of 'mounting' work properly.

	Note the XP boxes (one desktop and one laptop) I've been trying this 
out on still have their basic permissions set for the system partitions. 
  However, the initial XP box I worked on I had overridden those 
permissions by opening them up (giving Everyone full rights at the root 
level) on the data partition.  However, this should have no bearing, as 
Cygwin was installed on the C:\ system partition.

	So that brings me back to file permissions once again...though the fact 
that 'postgres' does not even SEE ipc-daemon makes me wonder just where 
the trouble lies.  Now for the big question:  If I set the environment 
variable 'CYGWIN=nontsec' and reboot, will that truly rule out file 
permissions as a culprit?

	I get the impression that this whole ntsec business isn't the cleanest 
thing.  I can't imagine exactly how they overlaid the *nix file 
permissions on an NT file system, as they are so different in nature 
(basic owner/group/world permissions versus ACLs).  Throw in the whole 
'Everyone' vs. 'Authenticated Users' business in NT, and who knows what 
else...  ANYWAY, my point is this:  If I set CYGWIN as stated, reboot, 
and try again, what will this definitely say, if anything?