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?