Re: [pgsql-hackers-win32] More SSL questions..
OK ... are you supposed to find it out by looking at the environment
vars, or is there another API defined?I am planning to consolidate the platform dependency into a function
defined likestatic bool pqGetHomeDirectory(char *buf, int bufsize)
{
-- Obtain pathname of user's home directory, store in
-- buf[] (of size bufsize)
-- Return TRUE if succeeded, FALSE if not
}If someone can whip up and test a WIN32 version of this,
I'll take care
of the rest.
I can't do the coding, but I took a quick look at msdn and I
think this is relevant:http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/shellcc/platform/shell/reference/functions/shgetfolderpath.aspHRESULT SHGetFolderPath(
HWND /hwndOwner/,
int /nFolder/,
HANDLE /hToken/,
DWORD /dwFlags/,
LPTSTR /pszPath/
);Also, for nFolder, it looks like the we want to use a value
of CSIDL_PROFILE (0x0028).Hope that helps someone out there.
No, we should use CSIDL_APPDATA. Two reasons:
1) Never put things in the root of the profile :P
2) CSIDL_APPDATA is supported on 9x (4.71 of the shell which,IIRC, is
Win95, as long as you have IE4 or newer install. And I doubt a lot of
people don't have that). Remember that our *client side code* support
9x.
(Then of course it should have "postgresql" (or ".postgresql" for
consiscency with *nix) appended to it)
Also, SHGetFolderPath() rqeuires Win2k. There is
SHGetSpecialFolderPath() for all versions.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc
/platform/shell/reference/functions/shgetspecialfolderpath.asp
Tom also wrote:
Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
"home directory". In particular ~/.pgpass is sought > there, and psql
also uses get_home_path in a lot of places.
Seems like we should be consistent about this --- either we trust
$HOME or we don't.
Don't trust $HOME on win32. There is no such thing.It's set by Cygwin,
and it's set by the MingW shell, but it's not set by Windows. HOMEDRIVE,
HOMEPATH and HOMESHARE are set, but not HOME.
You can trust USERPROFILE in NT based OSes. Not sure about 9x. Using the
API above is a much nicer way of doing it.
So, a quick implementation (not tested, but shouldn't be too hard) of
your functino would be:
static bool pqGetHomeDirectory(char *buf, int bufsize)
{
char tmppath[MAX_PATH+16]; /* Add 16 chars for "/.postgresql/"
*/
ZeroMemory(tmppath,sizeof(tmppath));
if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA,
FALSE)) {
return FALSE;
strcat(tmppath,"/.postgresql/");
if (strlen(tmppath) > bufsize)
return FALSE; /* Better than returning a chopped-off
path */
strcpy(buf, tmppath);
return TRUE;
}
You're going to have to add #include <shlobj.h> to the file as well.
//Magnus
Magnus Hagander said:
So, a quick implementation (not tested, but shouldn't be too hard) of
your functino would be:
static bool pqGetHomeDirectory(char *buf, int bufsize)
{
char tmppath[MAX_PATH+16]; /* Add 16 chars for "/.postgresql/"
*/
ZeroMemory(tmppath,sizeof(tmppath));
if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA,
FALSE)) {
return FALSE;
strcat(tmppath,"/.postgresql/");
if (strlen(tmppath) > bufsize)
return FALSE; /* Better than returning a chopped-off
path */
strcpy(buf, tmppath);
return TRUE;
}You're going to have to add #include <shlobj.h> to the file as well.
Excellent. I would suggest that we allow an environment variable PGHOME to
override this on all platforms, falling back to the above on Windows and
HOME elsewhere.
cheers
andrew
"Magnus Hagander" <mha@sollentuna.net> writes:
Tom also wrote:
Now that I look at it, there are several places that are depending on
getenv("HOME") or getenv("USERPROFILE") (on Windows) as the meaning of
"home directory". In particular ~/.pgpass is sought there, and psql
also uses get_home_path in a lot of places.
Seems like we should be consistent about this --- either we trust
$HOME or we don't.
Don't trust $HOME on win32. There is no such thing.It's set by Cygwin,
and it's set by the MingW shell, but it's not set by Windows. HOMEDRIVE,
HOMEPATH and HOMESHARE are set, but not HOME.
You can trust USERPROFILE in NT based OSes. Not sure about 9x. Using the
API above is a much nicer way of doing it.
We are using $USERPROFILE, not $HOME, on Windows, but I think Magnus is
right: we shouldn't be doing that at all. If I don't hear any
objections soon, I'm going to replace get_home_path() with code that
uses getpwuid (on Unix) or SHGetSpecialFolderPath (on Windows).
regards, tom lane
"Andrew Dunstan" <andrew@dunslane.net> writes:
Excellent. I would suggest that we allow an environment variable PGHOME to
override this on all platforms, falling back to the above on Windows and
HOME elsewhere.
Given that this code is mainly used to find security-critical files
(.pgpass and SSL certificates), I'm not sure that an override is a good
idea. I'm not dead set against it though --- any other opinions out
there?
Also, how do we document this behavior on Windows? The libpq docs
currently talk about, eg,
the connection in <filename>$HOME/.pgpass</> (or
<filename>%USERPROFILE%\.pgpass</> on Microsoft Windows).
but I'm not sure that's accurate or useful. Is there a phrase
comparable to "home directory" that will be understood by Windows
users? I'm thinking of writing "~/.pgpass" for the Unix case to
avoid giving the impression that we depend on getenv("HOME"),
because we won't anymore.
regards, tom lane
Tom Lane wrote:
"Andrew Dunstan" <andrew@dunslane.net> writes:
Excellent. I would suggest that we allow an environment variable PGHOME to
override this on all platforms, falling back to the above on Windows and
HOME elsewhere.Given that this code is mainly used to find security-critical files
(.pgpass and SSL certificates), I'm not sure that an override is a good
idea. I'm not dead set against it though --- any other opinions out
there?
If that's a valid concern (and it might well be) then we shouldn't rely
on any environment variable, including HOME - on Unix at least one could
use getpwent() and friends.
cheers
andrew
My feeling is that the *.txt is actually misleading because
people will
think of it as a file full of freeform text (paragraphs) and not a
configuration file.Why would they think that? If notepad tends to auto-wrap files then
this argument has some force; I'm not very familar with it though.
It does not. There is an option to make it *show* the file with wrapped
line, but it does not even have the capability to wordwrap the files
themselves.
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.
//Magnus
Import Notes
Resolved by subject fallback
Magnus Hagander wrote:
My feeling is that the *.txt is actually misleading because
people will
think of it as a file full of freeform text (paragraphs) and not a
configuration file.Why would they think that? If notepad tends to auto-wrap files then
this argument has some force; I'm not very familar with it though.It does not. There is an option to make it *show* the file with wrapped
line, but it does not even have the capability to wordwrap the files
themselves.FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.
Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the current
*.txt names. We can either leave it unchanged, remove *.txt, or change
it to *.config.
Currently the two Win32 files with *.txt extensions are:
APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txt
*.txt was added on Win32 to make them automatically start notepad.exe
when clicked on. Here is a copy of the Mozilla directory on XP:
[.] [..] 1138945.s 1138945.w
abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html
bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html
[Cache] [Cache.Trash] cert8.db [chatzilla]
[chrome] cookies.txt cookperm.txt downloads.rdf
history.dat history.mab hostperm.1 key3.db
localstore.rdf [Mail] mailViews.dat mimeTypes.rdf
panacea.dat panels.rdf parent.lock prefs.js
search.rdf secmod.db URL.tbl XUL.mfl
There are no *.txt files even though they are all text files. They are
not meant to be edited by hand though. I don't have any *.txt files
under \Application Data on my machine.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian wrote:
[.] [..] 1138945.s 1138945.w
abook.mab bookmarks-1.html bookmarks-2.html bookmarks-3.html
bookmarks-4.html bookmarks-5.html bookmarks-6.html bookmarks.html
[Cache] [Cache.Trash] cert8.db [chatzilla]
[chrome] cookies.txt cookperm.txt downloads.rdf
history.dat history.mab hostperm.1 key3.db
localstore.rdf [Mail] mailViews.dat mimeTypes.rdf
panacea.dat panels.rdf parent.lock prefs.js
search.rdf secmod.db URL.tbl XUL.mflThere are no *.txt files even though they are all text files. They are
Oops, sorry there are two *.txt files for cookies, but most of the
configuration files are not *.txt.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian wrote:
Magnus Hagander wrote:
My feeling is that the *.txt is actually misleading because
people will
think of it as a file full of freeform text (paragraphs) and not a
configuration file.Why would they think that? If notepad tends to auto-wrap files then
this argument has some force; I'm not very familar with it though.It does not. There is an option to make it *show* the file with wrapped
line, but it does not even have the capability to wordwrap the files
themselves.FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the current
*.txt names. We can either leave it unchanged, remove *.txt, or change
it to *.config.
APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txt
Another idea is to use *.conf. We already have:
pg_hba.conf
pg_ident.conf
pg_service.conf
postgresql.conf
recovery.conf
If we want an extension on those two files, it seems *.conf is it, and
one hopes they would have already configured XP to pull up their
favorite editor for *.conf.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the
current *.txt names. We can either leave it unchanged,remove *.txt,
or change it to *.config.
APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txtAnother idea is to use *.conf. We already have:
pg_hba.conf
pg_ident.conf
pg_service.conf
postgresql.conf
recovery.confIf we want an extension on those two files, it seems *.conf
is it, and one hopes they would have already configured XP to
pull up their favorite editor for *.conf.
Personally, I don't really care :-) My point was that ".pgpass" is bad.
"pgpass" or "pgpass.conf" or "pgpass.txt" are all fine by me. I agree
that .conf might be more logical than .txt.
//Magnus
Import Notes
Resolved by subject fallback
"Magnus Hagander" <mha@sollentuna.net> writes:
Personally, I don't really care :-) My point was that ".pgpass" is bad.
"pgpass" or "pgpass.conf" or "pgpass.txt" are all fine by me. I agree
that .conf might be more logical than .txt.
I think the analogy to .conf is bogus. The existing files named .conf
are server config not client config, and they don't have leading dots
in their names on Unix either.
Also, the whole point of this exercise is to make these files easy to
edit for newbies. The fact that an association *could* be configured
for .conf seems to me to miss the point: anyone who knows enough to do
that wouldn't have a problem with any spelling whatever...
regards, tom lane
Tom Lane wrote:
"Magnus Hagander" <mha@sollentuna.net> writes:
Personally, I don't really care :-) My point was that ".pgpass" is bad.
"pgpass" or "pgpass.conf" or "pgpass.txt" are all fine by me. I agree
that .conf might be more logical than .txt.I think the analogy to .conf is bogus. The existing files named .conf
are server config not client config, and they don't have leading dots
in their names on Unix either.
I don't think it is bogus. The reason our client config files don't
have *.conf is because they have dots --- the leading dot says it is a
config file to me. Win32 doesn't support leading dots mean config files
so we add *.conf. Also, pg_service.conf is a client file used by libpq.
I don't see why file extensions for the server should not also be
similar for clients.
Also, the whole point of this exercise is to make these files easy to
edit for newbies. The fact that an association *could* be configured
for .conf seems to me to miss the point: anyone who knows enough to do
that wouldn't have a problem with any spelling whatever...
What I am saying is that no one else uses *.txt for config files on
Win32 and it is confusing. The *.txt will confuse everyone, experts and
novices, while *.conf is clear but will be a little harder for novices
to open. Also remember the files will normally not exist so novices are
going to have to create those files first anyway.
At this point, Andrew, Magnus, and I who deal with Win32 regularly all
feel *.conf is more logical than *.txt. I have not heard anyone say
*.txt is better except Tom. Is that enough of a vote?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> writes:
At this point, Andrew, Magnus, and I who deal with Win32 regularly all
feel *.conf is more logical than *.txt. I have not heard anyone say
*.txt is better except Tom. Is that enough of a vote?
AFAIR they both said they didn't care; you are the only one who is
exercised about this.
I don't particularly care either, but I do note that Peter already
generated what was supposed to be the final version of the man pages,
and we can't change this without changing those.
Do what you want; I have more important problems to worry about right now.
regards, tom lane
Bruce Momjian wrote:
At this point, Andrew, Magnus, and I who deal with Win32 regularly all
feel *.conf is more logical than *.txt. I have not heard anyone say
*.txt is better except Tom. Is that enough of a vote?
*ahem* :-) I though what I said was that we should leave the name alone
except for removing a leading dot. I have seen other cases where .foorc
became foo.rc on windows, which isn't a bad solution for such files.
I honestly don't care that much - it's not worth a religious fight over.
cheers
andrew
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the current
*.txt names. We can either leave it unchanged, remove *.txt, or change
it to *.config.APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txtAnother idea is to use *.conf.
For what it's worth, I always thought that text configuration files on
Windows platforms generally used the '.ini' extension. I believe on
most Windows systems that extension is by default associated with
Notepad.
--
Kevin Brown kevin@sysexperts.com
Kevin Brown wrote:
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the current
*.txt names. We can either leave it unchanged, remove *.txt, or change
it to *.config.APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txtAnother idea is to use *.conf.
For what it's worth, I always thought that text configuration files on
Windows platforms generally used the '.ini' extension. I believe on
most Windows systems that extension is by default associated with
Notepad.
The problem with *.ini is that it suggests we follow the INI file format
for those files, which we don't.
Given the recent votes I have made the following patch which changes the
*.txt extensions to *.conf. It is consistent with our other config
files on the server side. This change is for Win32 only. I will apply
for 8.0 soon.
One additional issue is that we currently specify the client directory
as %APPDATA%\postgresql\, but in my "Application Data" directory most of
my directories are upper/lower case, suggesting that we should use
%APPDATA%\PostgreSQL\. Win32 is case-insensitve but case-preserving so
they directory could be created with any case but it seems we should
suggest directory capitalization more consistent with Win32.
Comments?
We are at the point where we are really just polishing Win32 and these
issues are all cosmetic.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/pgpatches/txttext/plainDownload
Index: doc/src/sgml/libpq.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.177
diff -c -c -r1.177 libpq.sgml
*** doc/src/sgml/libpq.sgml 8 Jan 2005 22:13:28 -0000 1.177
--- doc/src/sgml/libpq.sgml 13 Jan 2005 15:47:39 -0000
***************
*** 3883,3889 ****
that can contain passwords to be used if the connection requires a
password (and no password has been specified otherwise).
On Microsoft Windows the file is named
! <filename>%APPDATA%\postgresql\pgpass.txt</> (where <filename>%APPDATA%</>
refers to the Application Data subdirectory in the user's profile).
</para>
--- 3883,3889 ----
that can contain passwords to be used if the connection requires a
password (and no password has been specified otherwise).
On Microsoft Windows the file is named
! <filename>%APPDATA%\postgresql\pgpass.conf</> (where <filename>%APPDATA%</>
refers to the Application Data subdirectory in the user's profile).
</para>
Index: doc/src/sgml/ref/psql-ref.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.129
diff -c -c -r1.129 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 6 Jan 2005 21:20:44 -0000 1.129
--- doc/src/sgml/ref/psql-ref.sgml 13 Jan 2005 15:47:45 -0000
***************
*** 2525,2531 ****
<filename>psqlrc</filename> file and the user's
<filename>~/.psqlrc</filename> file.
(On Windows, the user's startup file is named
! <filename>%APPDATA%\postgresql\psqlrc.txt</filename>.)
See <filename><replaceable>PREFIX</>/share/psqlrc.sample</>
for information on setting up the system-wide file. It could be used
to set up the client or the server to taste (using the <command>\set
--- 2525,2531 ----
<filename>psqlrc</filename> file and the user's
<filename>~/.psqlrc</filename> file.
(On Windows, the user's startup file is named
! <filename>%APPDATA%\postgresql\psqlrc.conf</filename>.)
See <filename><replaceable>PREFIX</>/share/psqlrc.sample</>
for information on setting up the system-wide file. It could be used
to set up the client or the server to taste (using the <command>\set
Index: src/bin/psql/startup.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.109
diff -c -c -r1.109 startup.c
*** src/bin/psql/startup.c 6 Jan 2005 18:29:09 -0000 1.109
--- src/bin/psql/startup.c 13 Jan 2005 15:47:51 -0000
***************
*** 48,54 ****
#define PSQLRC ".psqlrc"
#else
#define SYSPSQLRC "psqlrc"
! #define PSQLRC "psqlrc.txt"
#endif
/*
--- 48,54 ----
#define PSQLRC ".psqlrc"
#else
#define SYSPSQLRC "psqlrc"
! #define PSQLRC "psqlrc.conf"
#endif
/*
Index: src/interfaces/libpq/fe-connect.c
===================================================================
RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.300
diff -c -c -r1.300 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 10 Jan 2005 00:19:43 -0000 1.300
--- src/interfaces/libpq/fe-connect.c 13 Jan 2005 15:47:57 -0000
***************
*** 69,75 ****
#ifndef WIN32
#define PGPASSFILE ".pgpass"
#else
! #define PGPASSFILE "pgpass.txt"
#endif
/* fall back options if they are not specified by arguments or defined
--- 69,75 ----
#ifndef WIN32
#define PGPASSFILE ".pgpass"
#else
! #define PGPASSFILE "pgpass.conf"
#endif
/* fall back options if they are not specified by arguments or defined
I have no problems with the patch ...
On Thu, 13 Jan 2005, Bruce Momjian wrote:
Kevin Brown wrote:
Bruce Momjian wrote:
FWIW, I've seen several apps that use .txt for config files, but I can't
think of an example right now. Most don't though - .cfg or .conf is
probably most common. Except for the majority of windows programs that
don't use config files - they use the registry. But I see no reason *at
all* for us to want to do that :-) It also more or less requires you to
write a GUI to change the config stuff and in that case the file
extension becomes irrelevant.Where are we on this? I think Andrew and I both think *.txt is
confusing. We need to decide on Monday if we should change the current
*.txt names. We can either leave it unchanged, remove *.txt, or change
it to *.config.APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txtAnother idea is to use *.conf.
For what it's worth, I always thought that text configuration files on
Windows platforms generally used the '.ini' extension. I believe on
most Windows systems that extension is by default associated with
Notepad.The problem with *.ini is that it suggests we follow the INI file format
for those files, which we don't.Given the recent votes I have made the following patch which changes the
*.txt extensions to *.conf. It is consistent with our other config
files on the server side. This change is for Win32 only. I will apply
for 8.0 soon.One additional issue is that we currently specify the client directory
as %APPDATA%\postgresql\, but in my "Application Data" directory most of
my directories are upper/lower case, suggesting that we should use
%APPDATA%\PostgreSQL\. Win32 is case-insensitve but case-preserving so
they directory could be created with any case but it seems we should
suggest directory capitalization more consistent with Win32.Comments?
We are at the point where we are really just polishing Win32 and these
issues are all cosmetic.-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664