Обсуждение: Re: [BUGS] More SSL questions..
>> The comment in the API for the profile directory says: >> Version 5.0. The user's profile folder. A typical path is >C:\Documents >> and Settings\username. Applications should not create files >or folders >> at this level; they should put their data under the >locations referred >> to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. >> >> I think we should stay away from that one if possible. >> >> For the MSI install we could always add icons to edit the >config file if >> people have a hard time finding it... >> >> The files are not hidden any more than they are hidden on >unix by being >> named ".postgresql". I don't see this as a big problem. > >With Unix you know you can do cd .postgresql or 'ls -a'. I think on >Win32 almost everyone is using the file explorer and I don't see any >clean way for them to get into "Application Data" other than by >modifying the directory properties. Do you? First of all, I can confirm that on a completely fresh XP installation the folder *is* hidden. In case it was still needed confirmation. The equivalent command on windows is "dir /a". Works just fine. Just use dir /a "%USERPROFILE%" will show application data just fine. Or for that matter cd "%USERPROFILE%\Application Data". Or if you start a fresh commandprompt I think it defaults to your profile dir in which case you just do cd "Application Data". Oh, and tab-complete works fine with hidden folders... A user who doesn't know to use the commandline and doesn't know how to view hidden files in the Explorer (which for anybody who works with windows past office is the first thing they turn on in a new install) is going to be confused *no matter where the file is*. Because he needs to find the file. And since the file is not ".txt", it doesn't open with notepad when double-clicked - it brings up a weird dialog asking you if you want to go to a MS web service to get help to determine which program to use to open the file. And hell, it's a *textfile*, where is the GUI. If he can get past the double-click and hey-its-a-textfile, then the fact that it's in the *windows standard location* is not going to give him much problems, even if the standard location is hidden by default. Bottom line: I think you're greatly overestimating the trouble caused by the fact that the appdata folder is hidden. //Magnus
"Magnus Hagander" <mha@sollentuna.net> writes:
> ... And since the file is not ".txt", it doesn't open with
> notepad when double-clicked - it brings up a weird dialog asking you if
> you want to go to a MS web service to get help to determine which
> program to use to open the file. And hell, it's a *textfile*, where is
> the GUI. If he can get past the double-click and hey-its-a-textfile,
> then the fact that it's in the *windows standard location* is not going
> to give him much problems, even if the standard location is hidden by
> default.
We were already speaking of getting rid of the leading dot. If the name
is different at all from the Unix case, it'd be trivial to make it
"psqlrc.txt" and "pgpass.txt" (I don't think the other ones need to be
edited).
> Bottom line: I think you're greatly overestimating the trouble caused by
> the fact that the appdata folder is hidden.
Whether we're overestimating it or not, we have to make a decision and
we have to make it now. This thread is singlehandedly delaying the 8.0
release. Since I haven't seen any serious alternative proposed, I think
we have to go with the CSIDL_APPDATA reference point.
Given that decision it seems like the best names are
APPDATA/postgresql/pgpass.txt
APPDATA/postgresql/psqlrc.txt
APPDATA/postgresql/psql_history
APPDATA/postgresql/postgresql.crt
APPDATA/postgresql/postgresql.key
APPDATA/postgresql/root.crt
Objections?
regards, tom lane
Tom Lane wrote: >Whether we're overestimating it or not, we have to make a decision and >we have to make it now. This thread is singlehandedly delaying the 8.0 >release. Since I haven't seen any serious alternative proposed, I think >we have to go with the CSIDL_APPDATA reference point. > >Given that decision it seems like the best names are > > APPDATA/postgresql/pgpass.txt > APPDATA/postgresql/psqlrc.txt > APPDATA/postgresql/psql_history > APPDATA/postgresql/postgresql.crt > APPDATA/postgresql/postgresql.key > APPDATA/postgresql/root.crt > >Objections? > None. Looks good to me. BTW, I agree with Magnus's argument that we are overestimating the cost of it being hidden.
"Matthew T. O'Connor" <matthew@zeut.net> writes:
> Tom Lane wrote:
>> Whether we're overestimating it or not, we have to make a decision and
>> we have to make it now. This thread is singlehandedly delaying the 8.0
>> release. Since I haven't seen any serious alternative proposed, I think
>> we have to go with the CSIDL_APPDATA reference point.
>>
>> Given that decision it seems like the best names are
>>
>> APPDATA/postgresql/pgpass.txt
>> APPDATA/postgresql/psqlrc.txt
>> APPDATA/postgresql/psql_history
>> APPDATA/postgresql/postgresql.crt
>> APPDATA/postgresql/postgresql.key
>> APPDATA/postgresql/root.crt
>>
>> Objections?
>>
> None. Looks good to me.
BTW, I did not get any guidance on how best to refer to this directory
in the documentation.
regards, tom lane
Tom Lane wrote: > "Matthew T. O'Connor" <matthew@zeut.net> writes: > > Tom Lane wrote: > >> Whether we're overestimating it or not, we have to make a decision and > >> we have to make it now. This thread is singlehandedly delaying the 8.0 > >> release. Since I haven't seen any serious alternative proposed, I think > >> we have to go with the CSIDL_APPDATA reference point. > >> > >> Given that decision it seems like the best names are > >> > >> APPDATA/postgresql/pgpass.txt > >> APPDATA/postgresql/psqlrc.txt > >> APPDATA/postgresql/psql_history > >> APPDATA/postgresql/postgresql.crt > >> APPDATA/postgresql/postgresql.key > >> APPDATA/postgresql/root.crt > >> > >> Objections? > >> > > > None. Looks good to me. > > BTW, I did not get any guidance on how best to refer to this directory > in the documentation. I would not use the *.txt. I think we just remove the dots and that is it. Most config files on XP don't have *.txt so adding it isn't giving us much, and as Magnus said someone who finds it is going to know how to open it in wordpad. To me *.txt identifies a description files like a README, not a config file to be modified. -- 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
Tom Lane <tgl@sss.pgh.pa.us> writes:
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
>> Tom Lane wrote:
>>> Whether we're overestimating it or not, we have to make a decision and
>>> we have to make it now. This thread is singlehandedly delaying the 8.0
>>> release. Since I haven't seen any serious alternative proposed, I think
>>> we have to go with the CSIDL_APPDATA reference point.
>>>
>>> Given that decision it seems like the best names are
>>>
>>> APPDATA/postgresql/pgpass.txt
>>> APPDATA/postgresql/psqlrc.txt
>>> APPDATA/postgresql/psql_history
>>> APPDATA/postgresql/postgresql.crt
>>> APPDATA/postgresql/postgresql.key
>>> APPDATA/postgresql/root.crt
>>>
>>> Objections?
>> None. Looks good to me.
I have applied code changes that do this. It still seems to work on
Unix but would someone verify behavior on WIN32? (You should also be
able to get SSL to work on WIN32 now, even with root.crt.)
> BTW, I did not get any guidance on how best to refer to this directory
> in the documentation.
Still an open question. I committed docs changes that refer to the
files exactly as above ("APPDATA/...") but obviously we have to adjust
that.
regards, tom lane
Magnus, where are you on getting a patch to fe-connect.c::pqGetHomeDirectory() for Win32? Right now the code is reading USERPROFILE or HOME. --------------------------------------------------------------------------- Magnus Hagander wrote: > >> The comment in the API for the profile directory says: > >> Version 5.0. The user's profile folder. A typical path is > >C:\Documents > >> and Settings\username. Applications should not create files > >or folders > >> at this level; they should put their data under the > >locations referred > >> to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. > >> > >> I think we should stay away from that one if possible. > >> > >> For the MSI install we could always add icons to edit the > >config file if > >> people have a hard time finding it... > >> > >> The files are not hidden any more than they are hidden on > >unix by being > >> named ".postgresql". I don't see this as a big problem. > > > >With Unix you know you can do cd .postgresql or 'ls -a'. I think on > >Win32 almost everyone is using the file explorer and I don't see any > >clean way for them to get into "Application Data" other than by > >modifying the directory properties. Do you? > > First of all, I can confirm that on a completely fresh XP installation > the folder *is* hidden. In case it was still needed confirmation. > > > > The equivalent command on windows is "dir /a". Works just fine. Just use > dir /a "%USERPROFILE%" > will show application data just fine. > > Or for that matter cd "%USERPROFILE%\Application Data". Or if you start > a fresh commandprompt I think it defaults to your profile dir in which > case you just do cd "Application Data". Oh, and tab-complete works fine > with hidden folders... > > A user who doesn't know to use the commandline and doesn't know how to > view hidden files in the Explorer (which for anybody who works with > windows past office is the first thing they turn on in a new install) is > going to be confused *no matter where the file is*. Because he needs to > find the file. And since the file is not ".txt", it doesn't open with > notepad when double-clicked - it brings up a weird dialog asking you if > you want to go to a MS web service to get help to determine which > program to use to open the file. And hell, it's a *textfile*, where is > the GUI. If he can get past the double-click and hey-its-a-textfile, > then the fact that it's in the *windows standard location* is not going > to give him much problems, even if the standard location is hidden by > default. > > Bottom line: I think you're greatly overestimating the trouble caused by > the fact that the appdata folder is hidden. > > //Magnus > -- 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
Tom Lane wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > "Matthew T. O'Connor" <matthew@zeut.net> writes:
> >> Tom Lane wrote:
> >>> Whether we're overestimating it or not, we have to make a decision and
> >>> we have to make it now. This thread is singlehandedly delaying the 8.0
> >>> release. Since I haven't seen any serious alternative proposed, I think
> >>> we have to go with the CSIDL_APPDATA reference point.
> >>>
> >>> Given that decision it seems like the best names are
> >>>
> >>> APPDATA/postgresql/pgpass.txt
> >>> APPDATA/postgresql/psqlrc.txt
> >>> APPDATA/postgresql/psql_history
> >>> APPDATA/postgresql/postgresql.crt
> >>> APPDATA/postgresql/postgresql.key
> >>> APPDATA/postgresql/root.crt
> >>>
> >>> Objections?
>
> >> None. Looks good to me.
>
> I have applied code changes that do this. It still seems to work on
> Unix but would someone verify behavior on WIN32? (You should also be
> able to get SSL to work on WIN32 now, even with root.crt.)
>
> > BTW, I did not get any guidance on how best to refer to this directory
> > in the documentation.
>
> Still an open question. I committed docs changes that refer to the
> files exactly as above ("APPDATA/...") but obviously we have to adjust
> that.
I just checked and %APPDATA% is defined on XP. It is not defined on
Win98. Not sure what the function Magnus is suggesting returns on that
platform.
So, you could use "%APPDATA%\...".
--
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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Magnus, where are you on getting a patch to
> fe-connect.c::pqGetHomeDirectory() for Win32? Right now the code is
> reading USERPROFILE or HOME.
Nope; as of CVS tip it's
#else
char tmppath[MAX_PATH];
ZeroMemory(tmppath, sizeof(tmppath));
if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA, FALSE))
return false;
snprintf(ret_path, MAXPGPATH, "%s/postgresql", tmppath);
return true;
#endif
This needs to be tested of course.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Magnus, where are you on getting a patch to > > fe-connect.c::pqGetHomeDirectory() for Win32? Right now the code is > > reading USERPROFILE or HOME. > > Nope; as of CVS tip it's > > #else > char tmppath[MAX_PATH]; > > ZeroMemory(tmppath, sizeof(tmppath)); > if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA, FALSE)) > return false; > snprintf(ret_path, MAXPGPATH, "%s/postgresql", tmppath); > return true; > #endif > > This needs to be tested of course. Uh, by default this directory is not going to exist, right? It doesn't in Unix home directories. And we need to change that to upper/lower "PostgreSQL", though that will not make a difference on Win32. -- 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA, FALSE))
>> return false;
>> snprintf(ret_path, MAXPGPATH, "%s/postgresql", tmppath);
>>
>> This needs to be tested of course.
> Uh, by default this directory is not going to exist, right?
The /postgresql subdirectory probably ought to be created by the Windows
installer. I don't think libpq ought to do it.
> And we need to change that to upper/lower
> "PostgreSQL", though that will not make a difference on Win32.
Weren't you just arguing to make the filenames as little different from
Unix as possible?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> if (!SHGetSpecialFolderPath(NULL, tmppath, CSIDL_APPDATA, FALSE)) > >> return false; > >> snprintf(ret_path, MAXPGPATH, "%s/postgresql", tmppath); > >> > >> This needs to be tested of course. > > > Uh, by default this directory is not going to exist, right? > > The /postgresql subdirectory probably ought to be created by the Windows > installer. I don't think libpq ought to do it. > > > And we need to change that to upper/lower > > "PostgreSQL", though that will not make a difference on Win32. > > Weren't you just arguing to make the filenames as little different from > Unix as possible? Oh, yea, I was. Good point because I forgot the ssl stuff already uses postgresql as lower case. Never mind. -- 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