Thread: initdb crash

Hello,

i know it's just a developer version currently, but i downloaded the win32
binaries to give it a run. Everything worked fine until i tried to execute
the initdb command as stated in the instructions. First i executed it as
an admin user and yielded the following result:

creating configuration files ... ok
creating template1 database in c:/postgres/data/base/1 ... execution of
PostgreS
QL by a user with administrative permissions is not permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromise.  See the documentation for
more information on how to properly start the server.
child process was terminated by signal 1
initdb: failed
initdb: removing data directory "c:/postgres/data"


So I created a new restricted user postgres, switched to his account and
tried to execute initdb from there. The result was that the app crashed
(that box with error appeared), console output given below:

creating configuration files ... ok
creating template1 database in c:/postgres/data/base/1 ... child process
was ter
minated by signal 5
initdb: failed
initdb: removing data directory "c:/postgres/data"

I'm pretty sure all my environment variables are set correctly and that i
used the proper slashes at the proper places (just like stated in the
instructions that can be found on the win32 binaries site). I'm using
WinXP Home Edition.

Is this a known problem? How can i fix it?

Thank you very much for your answer!


-Matthias

On 4 Jul 2004 at 3:26, nitrogenycs@web.de wrote:

> creating configuration files ... ok
> creating template1 database in c:/postgres/data/base/1 ... child process
> was ter
> minated by signal 5
> initdb: failed
> initdb: removing data directory "c:/postgres/data"
>
> I'm pretty sure all my environment variables are set correctly and that i
> used the proper slashes at the proper places (just like stated in the
> instructions that can be found on the win32 binaries site). I'm using
> WinXP Home Edition.
>
> Is this a known problem? How can i fix it?
>
> Thank you very much for your answer!
>

This is just a guess, but check that the new user (postgres) has enough
permission on the folders that you are using for Postgresql. Since you
created the folders as an admin user, ordinary users may not have all
the required permissions.

System error 5 under windows is a "permission denied" error. I don't
know if Postgresql is reflecting that as a signal with the same number.

I'm sure someone will correct me if I'm wrong :-)

Cheers,
Gary.

>>
>> This is just a guess, but check that the new user (postgres)
>has enough
>> permission on the folders that you are using for Postgresql.
>Since you
>> created the folders as an admin user, ordinary users may not have all
>> the required permissions.
>>
>> System error 5 under windows is a "permission denied" error. I don't
>> know if Postgresql is reflecting that as a signal with the
>same number.
>>
>
>After i read your mail (thank you very much for it) i've set the
>file/folder permission for the c:\postgres folder so that the user
>postgres has full access to it just like every admin has (was
>a bit of a
>hassle cause u have to reboot into safe mode, but i got it).
>Unfortunately
>initdb still crashes in the same way. Then i tried to create
>the postgres
>folder in the home directory of the user which resulted in a
>crash too. Is
>c:\postgres the only folder i have to grant full permissions
>for or are
>there others, too (like some system stuff or sth)? Or is this rather a
>result from the fact that error 5 isn't a permission denied error?

It will require READ permissions on the system directories, as well as
all the subdirs of the install directory (including bin, lib etc).

It *will* say signalled by code 5 when it is actually exiting with
normal exitcode 5.


This is because of the WIFSIGNALED() macro in port.h.

Seems to me these macros are completely wrong for win32. And they are
under a FIXME header - I guess that could be why. Since win32 doesn't
actually detect signals (it has no concept of it in this context),
shouldn't it be something along the line of:

#define WEXITSTATUS(w)  (w & 0x7f)
#define WIFEXITED(w)    (1)
#define WIFSIGNALED(w)  (0)
#define WTERMSIG(w)     (0)


Comments?


//Magnus

On 4 Jul 2004 at 13:49, Magnus Hagander wrote:

> >>
> >> This is just a guess, but check that the new user (postgres)
> >has enough
> >> permission on the folders that you are using for Postgresql.
> >Since you
> >> created the folders as an admin user, ordinary users may not have all
> >> the required permissions.
> >>
> >> System error 5 under windows is a "permission denied" error. I don't
> >> know if Postgresql is reflecting that as a signal with the
> >same number.
> >>
> >
> >After i read your mail (thank you very much for it) i've set the
> >file/folder permission for the c:\postgres folder so that the user
> >postgres has full access to it just like every admin has (was
> >a bit of a
> >hassle cause u have to reboot into safe mode, but i got it).
> >Unfortunately
> >initdb still crashes in the same way. Then i tried to create
> >the postgres
> >folder in the home directory of the user which resulted in a
> >crash too. Is
> >c:\postgres the only folder i have to grant full permissions
> >for or are
> >there others, too (like some system stuff or sth)? Or is this rather a
> >result from the fact that error 5 isn't a permission denied error?
>
> It will require READ permissions on the system directories, as well as
> all the subdirs of the install directory (including bin, lib etc).
>
> It *will* say signalled by code 5 when it is actually exiting with
> normal exitcode 5.
>
>
> This is because of the WIFSIGNALED() macro in port.h.
>
> Seems to me these macros are completely wrong for win32. And they are
> under a FIXME header - I guess that could be why. Since win32 doesn't
> actually detect signals (it has no concept of it in this context),
> shouldn't it be something along the line of:
>
> #define WEXITSTATUS(w)  (w & 0x7f)
> #define WIFEXITED(w)    (1)
> #define WIFSIGNALED(w)  (0)
> #define WTERMSIG(w)     (0)
>
>
> Comments?
>
>
> //Magnus
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

Am Sun, 04 Jul 2004 09:41:55 +0100 hat Gary Doades <gpd@gpdnet.co.uk>
geschrieben:
>
> This is just a guess, but check that the new user (postgres) has enough
> permission on the folders that you are using for Postgresql. Since you
> created the folders as an admin user, ordinary users may not have all
> the required permissions.
>
> System error 5 under windows is a "permission denied" error. I don't
> know if Postgresql is reflecting that as a signal with the same number.
>

After i read your mail (thank you very much for it) i've set the
file/folder permission for the c:\postgres folder so that the user
postgres has full access to it just like every admin has (was a bit of a
hassle cause u have to reboot into safe mode, but i got it). Unfortunately
initdb still crashes in the same way. Then i tried to create the postgres
folder in the home directory of the user which resulted in a crash too. Is
c:\postgres the only folder i have to grant full permissions for or are
there others, too (like some system stuff or sth)? Or is this rather a
result from the fact that error 5 isn't a permission denied error?

-Matthias

On 4 Jul 2004 at 13:49, Magnus Hagander wrote:

> >>
>
> It will require READ permissions on the system directories, as well as
> all the subdirs of the install directory (including bin, lib etc).
>

I guess this is another area that will have to be carefully explained to the Win32 user as
a consequence of not allowing Administrator to run initdb/postmaster.

I still don't see whats wrong with running as Administrator as long as TCPIP comms is
not enabled. It should be possible to restrict connection only from the local PC if running
as Administrator. This should not pose any security threat, should it?

Cheers,
Gary.

>hello,
>
>all the permissions u told me are already set (postgres
>subdirs + system
>dirs) and it doesn't work. Is it perhaps possible to make the
>output a bit
>more verbose so i can see which file/path caused the permission denied
>problem? Another idea might be to add an option so that i can
>force it to
>run under an admin user to figure out if that solves the
>problem. I don't
>know how difficult this is though.

Tru running initdb with the "-d" parameter. That should turn on some
debugging output.

//Magnus

>> It will require READ permissions on the system directories,
>as well as
>> all the subdirs of the install directory (including bin, lib etc).
>>
>
>I guess this is another area that will have to be carefully
>explained to the Win32 user as
>a consequence of not allowing Administrator to run initdb/postmaster.
>
>I still don't see whats wrong with running as Administrator as
>long as TCPIP comms is
>not enabled. It should be possible to restrict connection only
>from the local PC if running
>as Administrator. This should not pose any security threat, should it?

Can't run without TCPIP on win32...

Anyway. It is a security threat in the way that it helps an indirect
attack. Say a SQL injection attack would suddenly give you local admin
instead of just an unpriv account. A lot better place to get started if
you want to take over a server...

//Magnus

On 4 Jul 2004 at 14:37, Magnus Hagander wrote:

>
> Can't run without TCPIP on win32...

It should be possible to reject anything that is not 127.0.0.1

What about anonymous pipes? These are local only by definition. Maybe not for this
release. but maybe later?

>
> Anyway. It is a security threat in the way that it helps an indirect
> attack. Say a SQL injection attack would suddenly give you local admin
> instead of just an unpriv account. A lot better place to get started if
> you want to take over a server...

Absolutely! but...

You must have had admin privs to start the postmaster as an admin user anyway so why
is this a problem? I'm only suggesting that this would be easier for a developer on their
local system or all those folks out there who want to see what PostgreSQL can do. As
long as admin privs are restricted to the local system (by whatever means) then it should
be allowed.

You should definitely NOT be able to start postmaster with admin privs and give network
access.

Cheers,
Gary.

hello,

all the permissions u told me are already set (postgres subdirs + system
dirs) and it doesn't work. Is it perhaps possible to make the output a bit
more verbose so i can see which file/path caused the permission denied
problem? Another idea might be to add an option so that i can force it to
run under an admin user to figure out if that solves the problem. I don't
know how difficult this is though.

-Matthias

>> Can't run without TCPIP on win32...
>
>It should be possible to reject anything that is not 127.0.0.1

Oh yes. And bind to just 127.0.0.1. Should be safe with tcp, yes.


>What about anonymous pipes? These are local only by
>definition. Maybe not for this
>release. but maybe later?

I doubt we'd want to do those - that would be a whole new layer of code
in libpq, since they're not compatible with the socket calls.


>> Anyway. It is a security threat in the way that it helps an indirect
>> attack. Say a SQL injection attack would suddenly give you
>local admin
>> instead of just an unpriv account. A lot better place to get
>started if
>> you want to take over a server...
>
>Absolutely! but...
>
>You must have had admin privs to start the postmaster as an
>admin user anyway so why is this a problem?

This has nothing to do with possible attack vectors using SQL injection,
for example. The admin starts the service. The SQL injection comes in
though the webserver at a later time (and hey, if you don't even allow
that one to connect to your server, then don't bother running it).
Now sure, this is a bug in the web application, but there are thousands
of webapps out tehre with just this kind of bug. And by not allowing the
server to run as admin, we help the admins decrease the surface that
this kind of attack can actually hit.


>I'm only suggesting that this would be easier for a developer on their
>local system or all those folks out there who want to see what
>PostgreSQL can do. As
>long as admin privs are restricted to the local system (by
>whatever means) then it should be allowed.

How do you intend to prevent that? We don't even prevent that today. You
can have admin on the network but not on the local machine, and we
*will* let you start it. But there is no way to end up in that situation
without tweaking several locations.


The one argument I buy is the one for making it easier for developers. I
guess one way would be a commandline option that permits it to run as
admin. In doing this, it should also *FORCE* connections to permit
127.0.0.1 only, and emit a screenful of warnings about how bad this is.
But sure, in a developers VM or otherwise secured machine, it's not a
major issue.

Not sure if this would be accepted, though. Tom/others?


//Magnus

On 4 Jul 2004 at 15:47, Magnus Hagander wrote:

>
> This has nothing to do with possible attack vectors using SQL injection,
> for example. The admin starts the service. The SQL injection comes in
> though the webserver at a later time (and hey, if you don't even allow
> that one to connect to your server, then don't bother running it).
> Now sure, this is a bug in the web application, but there are thousands
> of webapps out tehre with just this kind of bug. And by not allowing the
> server to run as admin, we help the admins decrease the surface that
> this kind of attack can actually hit.
>

OK, I'll concede that one. I'd forgotten about web apps running on the same PC as the
DB.

> The one argument I buy is the one for making it easier for developers. I
> guess one way would be a commandline option that permits it to run as
> admin. In doing this, it should also *FORCE* connections to permit
> 127.0.0.1 only, and emit a screenful of warnings about how bad this is.
> But sure, in a developers VM or otherwise secured machine, it's not a
> major issue.
>

I think this is all the Win32 users are asking for, but given the above argument about
web apps it would still represent a small risk.

Thanks,
Gary.

"Magnus Hagander" <mha@sollentuna.net> writes:
> It *will* say signalled by code 5 when it is actually exiting with
> normal exitcode 5.

> This is because of the WIFSIGNALED() macro in port.h.

Hm.  Whether those macros are wrong or not, we're still left wondering
why it would exit(5), either.

The crash is apparently coming during the first attempt to insert a row
from the postgres.bki file.  That does not seem consistent with the
theory about a permissions problem; if we had no directory permissions
I'd have expected a failure at the previous "create pg_proc" step.  (For
that matter, how'd we have managed to create all the subdirectories and
configuration files?  The permissions theory doesn't hold water at all.)

            regards, tom lane

"Magnus Hagander" <mha@sollentuna.net> writes:
> Not sure if this would be accepted, though. Tom/others?

No, and it's irrelevant to this thread anyway.  Can we go back to
debugging the crash please?

            regards, tom lane

Sorry for continuing bitching on this :)

apparently initdb seems to execute a good bunch of statements before it
crashes.

/*
    Here's are a lot of debug messages like the next 5 lines which seem to
indicate success inserting and creating stuff
     (i've cut them to shorten this mail, if u need them, tell me)
*/
DEBUG:  inserting column 14 value "-"
DEBUG:  Typ == NULL, typeindex = 1
DEBUG:  inserted -> -
DEBUG:  inserting column 15 NULL
DEBUG:  inserting row oid 1242, 16 columns
child process was terminated by signal 5
initdb: failed

and then there's this sudden crash. It's strange it crashes right in the
middle. Any hints?


-Matthias

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the idea is if you give people the ability to run the server in
any fashion as an account with admin rights, they will leave it running
because it is "working" for them. So if the programs they want to run
only needs access to a local machine, then they would run in admin mode,
and just leave it. That leaves it open for someone else to escalate
their priveledges.

However, I do think it is safe enough (security is always a trade-off
after all.) If you really want it, you could allow administrator, but
not allow remote connections, and only run for a limited period of time.

I still think this person would benifit from figuring out how to get it
working as an unpriv. user, though. Actually, I think the best long-term
solution is to just have an installer that can create a local user
account, and install/initdb such that all permissions are right (I would
even suggest having it install only as a service). Then we wouldn't have
to worry about a lot of this.

John
=:->

Gary Doades wrote:
| On 4 Jul 2004 at 14:37, Magnus Hagander wrote:
|
|
|>Can't run without TCPIP on win32...
|
|
| It should be possible to reject anything that is not 127.0.0.1
|
| What about anonymous pipes? These are local only by definition. Maybe
not for this
| release. but maybe later?
|
|
|>Anyway. It is a security threat in the way that it helps an indirect
|>attack. Say a SQL injection attack would suddenly give you local admin
|>instead of just an unpriv account. A lot better place to get started if
|>you want to take over a server...
|
|
| Absolutely! but...
|
| You must have had admin privs to start the postmaster as an admin user
anyway so why
| is this a problem? I'm only suggesting that this would be easier for a
developer on their
| local system or all those folks out there who want to see what
PostgreSQL can do. As
| long as admin privs are restricted to the local system (by whatever
means) then it should
| be allowed.
|
| You should definitely NOT be able to start postmaster with admin privs
and give network
| access.
|
| Cheers,
| Gary.
|
| ---------------------------(end of broadcast)---------------------------
| TIP 2: you can get off all lists at once with the unregister command
|     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6B8IJdeBCYSNAAMRAkgsAJ4xjJTlw+GqbMOUPMpeUH3Xg44X/ACeMGeA
peOje5Ti2G/CsTOoUZ4zCUs=
=EWwP
-----END PGP SIGNATURE-----

On 4 Jul 2004 at 10:04, Tom Lane wrote:

> Hm.  Whether those macros are wrong or not, we're still left wondering
> why it would exit(5), either.
>
> The crash is apparently coming during the first attempt to insert a row
> from the postgres.bki file.  That does not seem consistent with the
> theory about a permissions problem; if we had no directory permissions
> I'd have expected a failure at the previous "create pg_proc" step.  (For
> that matter, how'd we have managed to create all the subdirectories and
> configuration files?  The permissions theory doesn't hold water at all.)
>
>             regards, tom lane

Yup, I can reproduce this as well. In fact I am now completely stuck. I can't run as
administrator and when I am an ordinary user I can't initdb.

It doesn't fully behave like a permissions issue. I have given full control to the unpriv
user to the entire drive that pgsql is on. Same problem. I have turned auditing on for file
access failure and no audit entries are generated.

It seems to create all the files, but the file "1255" in the pgsql\data\1 folder is zero bytes.

Cheers,
Gary.

On 4 Jul 2004 at 16:39, Gary Doades wrote:

> On 4 Jul 2004 at 10:04, Tom Lane wrote:
>
> > Hm.  Whether those macros are wrong or not, we're still left wondering
> > why it would exit(5), either.
> >
> > The crash is apparently coming during the first attempt to insert a row
> > from the postgres.bki file.  That does not seem consistent with the
> > theory about a permissions problem; if we had no directory permissions
> > I'd have expected a failure at the previous "create pg_proc" step.  (For
> > that matter, how'd we have managed to create all the subdirectories and
> > configuration files?  The permissions theory doesn't hold water at all.)
> >
> >             regards, tom lane
>

Hmm, I've just rebuilt this from the latest source snapshot tarball and it works perfectly.
Could this be a bad build of the binary on the snapshot website?

Cheers,
Gary.

>> > Hm.  Whether those macros are wrong or not, we're still
>left wondering
>> > why it would exit(5), either.
>> >
>> > The crash is apparently coming during the first attempt to
>insert a row
>> > from the postgres.bki file.  That does not seem consistent with the
>> > theory about a permissions problem; if we had no directory
>permissions
>> > I'd have expected a failure at the previous "create
>pg_proc" step.  (For
>> > that matter, how'd we have managed to create all the
>subdirectories and
>> > configuration files?  The permissions theory doesn't hold
>water at all.)
>> >
>> >             regards, tom lane
>>
>
>Hmm, I've just rebuilt this from the latest source snapshot
>tarball and it works perfectly.
>Could this be a bad build of the binary on the snapshot website?

It could be. It's starting to sound more and more like it. I've tried a
whole bunch of different permission sets on dirs/parents/etc, and I'm
completley unable to reproduce the problem.

Looking at the build switches, the difference is I'm building without
zlib and without ssl, but with asserts enabled. Unfort, my mingw env is
a bit broken, so I can't try it with zlib and ssl enabled. Could you try
that (the exact commandline is on the www.hagander.net/pgsql/win32snap/
page), and see if one of those switches is what causes the problem?

Merlin - can you comment on wether that commandline used to build is
correct or if it has changed lately, and wether you see the same
problem?


//Magnus

On 4 Jul 2004 at 19:31, Magnus Hagander wrote:

> Looking at the build switches, the difference is I'm building without
> zlib and without ssl, but with asserts enabled. Unfort, my mingw env is
> a bit broken, so I can't try it with zlib and ssl enabled. Could you try
> that (the exact commandline is on the www.hagander.net/pgsql/win32snap/
> page), and see if one of those switches is what causes the problem?
>
> Merlin - can you comment on wether that commandline used to build is
> correct or if it has changed lately, and wether you see the same
> problem?
>

I'm currently building without zlib and without ssl too. Unfortunately I'm completely new
to MinGW/msys and it appears that I don't have all the packages installed for zlib & ssl.

I'll go away and work out how to get what I need.

Cheers,
Gary.

When will you put up a fixed version of the binaries? Will it take long?

-Matthias

Is anyone getting this crash when installing on ntfs an partition or
only on fat32?  I have gotten the initdb crash installing on fat32.
Used xcacls to set permissions and got no errors!
However if an app is making use of these acls, I would assume that
it will crash.
Will try installing on ntfs partition soon.

Cheers,
Neil

----- Original Message -----
From: "Magnus Hagander" <mha@sollentuna.net>
To: "Gary Doades" <gpd@gpdnet.co.uk>; <pgsql-hackers-win32@postgresql.org>
Cc: "Merlin Moncure" <merlin.moncure@rcsonline.com>
Sent: Sunday, July 04, 2004 1:31 PM
Subject: Re: [pgsql-hackers-win32] initdb crash


>> > Hm.  Whether those macros are wrong or not, we're still
>left wondering
>> > why it would exit(5), either.
>> >
>> > The crash is apparently coming during the first attempt to
>insert a row
>> > from the postgres.bki file.  That does not seem consistent with the
>> > theory about a permissions problem; if we had no directory
>permissions
>> > I'd have expected a failure at the previous "create
>pg_proc" step.  (For
>> > that matter, how'd we have managed to create all the
>subdirectories and
>> > configuration files?  The permissions theory doesn't hold
>water at all.)
>> >
>> > regards, tom lane
>>
>
>Hmm, I've just rebuilt this from the latest source snapshot
>tarball and it works perfectly.
>Could this be a bad build of the binary on the snapshot website?

It could be. It's starting to sound more and more like it. I've tried a
whole bunch of different permission sets on dirs/parents/etc, and I'm
completley unable to reproduce the problem.

Looking at the build switches, the difference is I'm building without
zlib and without ssl, but with asserts enabled. Unfort, my mingw env is
a bit broken, so I can't try it with zlib and ssl enabled. Could you try
that (the exact commandline is on the www.hagander.net/pgsql/win32snap/
page), and see if one of those switches is what causes the problem?

Merlin - can you comment on wether that commandline used to build is
correct or if it has changed lately, and wether you see the same
problem?


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Neil Harrilall said:
> Is anyone getting this crash when installing on ntfs an partition or
> only on fat32?  I have gotten the initdb crash installing on fat32.
> Used xcacls to set permissions and got no errors!
> However if an app is making use of these acls, I would assume that  it
> will crash.
> Will try installing on ntfs partition soon.
>

Running on fat32 is just asking to be shot in the foot. If there is a simple
check to detect it I'd favor having initdb and/or postgres refuse to run on
fat32.

cheers

andrew

> > Is anyone getting this crash when installing on ntfs an
> partition or
> > only on fat32?  I have gotten the initdb crash installing on fat32.
> > Used xcacls to set permissions and got no errors!
> > However if an app is making use of these acls, I would
> assume that  it
> > will crash.
> > Will try installing on ntfs partition soon.
> >
>
> Running on fat32 is just asking to be shot in the foot. If
> there is a simple check to detect it I'd favor having initdb
> and/or postgres refuse to run on fat32.

You can use GetVolumeInformation() (see MSDN). This will get you both a
set of binary flags you can check for the capabilities we want
(FS_PERSISTENT_ACLS will exist on NTFS only, for example), and a char
buffer with the name of the filesystem.


//Magnus

This isn't just convenience, NTFS (Never The Same Filesystem) means not running
between multiple platforms.  And a crashed NTFS is harder to recover than a crashed
FAT32.  All I want to say is that they both have their good sides AND their bad sides.
If you don't work with multiple OS's on 1 system and a shared partition between them
the choice to make is definitely an NTFS, but there are other situations.  If you want
to try it, try to execute an older Partition Magic (7 or something) on an NTFS in W2K
or WXP.  But you better take a backup before you resize it.

Greetings
Deblauwe Gino

On 7 Jul 2004 at 4:25, Andrew Dunstan wrote:

>
> This is Postgres. Our motto is "We care about your data". You would have
> to work really really hard to convince me that convenience wins out over
> safety.
>
> cheers
>
> andrew
>
> Deblauwe Gino wrote:
>
> >Refuse to run on a account that has to much permissions: yes, otherwise you're just
> >asking for trouble.
> >FAT32 isn't good but it's more independent then NTFS which changes by each new
> >Windows if you're lucky, and by the next servicepack if they like it with of course no
> >guarantee at all for the compatibility.  I don't like the safety of FAT32 (it can fail and
> >you can't set permissions) but it's the only alternative to insure running 2 different
> >OS's on 1 PC and keep working with it.  You can give a warning...
> >
> >But that's only an opinion of course...
> >Greetings Gino
> >
> >On 6 Jul 2004 at 19:01, Andrew Dunstan wrote:
> >
> >
> >
> >>Neil Harrilall said:
> >>
> >>
> >>>Is anyone getting this crash when installing on ntfs an partition or
> >>>only on fat32?  I have gotten the initdb crash installing on fat32.
> >>>Used xcacls to set permissions and got no errors!
> >>>However if an app is making use of these acls, I would assume that  it
> >>>will crash.
> >>>Will try installing on ntfs partition soon.
> >>>
> >>>
> >>>
> >>Running on fat32 is just asking to be shot in the foot. If there is a simple
> >>check to detect it I'd favor having initdb and/or postgres refuse to run on
> >>fat32.
> >>
> >>cheers
> >>
> >>andrew
> >>
> >>
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 3: if posting/reading through Usenet, please send an appropriate
> >>      subscribe-nomail command to majordomo@postgresql.org so that your
> >>      message can get through to the mailing list cleanly
> >>
> >>
> >
> >
> >
> >
>

> From: Deblauwe Gino [mailto:De_Spike@Pandora.Be]
>
> This isn't just convenience, NTFS (Never The Same Filesystem)
> means not running between multiple platforms.

Notice that we don't support 9x anyway. We only support NT based
systems, and they all support NTFS.

> And a crashed
> NTFS is harder to recover than a crashed FAT32.  All I want
> to say is that they both have their good sides AND their bad sides.
> If you don't work with multiple OS's on 1 system and a shared
> partition between them the choice to make is definitely an
> NTFS, but there are other situations.

If they are both NT based, NTFS should not be a problem, or?


> > This is Postgres. Our motto is "We care about your data". You would
> > have to work really really hard to convince me that
> convenience wins
> > out over safety.

On the basis on this, btw, why don't we reject things like ext2 on
linux? Or any non-metadata-journalled FS (on any platforms)? Or at least
emit a warning. If we can detect it at all (I guess that could be why).
While not as bad as FAT for reliability, still not very good...

//Magnus

I think this is not really an apples-to-apples comparison :

- ext2 has persistent security permissions
- ext2 is considerably more robust than fat

Similar comments - but with more force in the second point - would apply
for the various ufs implementations.

regards

Mark

Magnus Hagander wrote:

>On the basis on this, btw, why don't we reject things like ext2 on
>linux? Or any non-metadata-journalled FS (on any platforms)? Or at least
>emit a warning. If we can detect it at all (I guess that could be why).
>While not as bad as FAT for reliability, still not very good...
>
>//Magnus
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>

> When will you put up a fixed version of the binaries? Will it take
long?

It appears to be a bad build of the binaries.  Unfortunately I've been
on vacation since Friday and missed this expect a fixed version by 10
a.m. Thursday morning EST.

Unfortunately the win32 task scheduler busted at exactly the wrong
moment. :(

Merlin