Apache on Vista: cannot find CSIDL_COMMON_APPDATA folder from CGIprogram

I'm cross-posting (or failing that, multiposting) to
comp.infosystems.www.servers.ms-windows and comp.os.ms-
windows.programmer.win32, because I don't know whether this is an
issue with the one, the other, or a mixture of both. I can't cross-
post it to the Subversion newsgroup, because there isn't one, but if
this discussion bears fruit I'll summarize it on their wiki.

I have Apache 2.2.11 installed on a stand-alone Windows Vista Ultimate
SP1 system. I have a CGI perl script which calls "svn.exe".

#!c:/strawberry/perl/bin/perl.exe
print "Content-type: text/plain;\n\n\n";
my $status = system "svn --version 2>&1";
print "svn exited with status $status.";

It works okay at the command line but when called as a CGI script, it
shows:
svn: Can't determine the system config path
svn exited with status 256.

The CGI script also works fine on the Windows XP SP3 systems I've
tried (Home and Professional Edition).

After looking at the source code for Subversion (see the function
"svn_config__win_config_path" in "subversion-1.6.1\subversion
\libsvn_subr\config_win.c"), I've reduced the example to this C++
program (it's wordy, but it just calls SHGetFolderPath):

#include <iostream>
#include <ostream>
#include <windows.h>
#include <shlobj.h>
const int SHGFP_TYPE_CURRENT = 0; // Not in my <shlobj.h> for some
reason
int main () {
const int csidl = CSIDL_COMMON_APPDATA;
char folder [MAX_PATH] = { 0 };
unsigned result = SHGetFolderPath (0, csidl, (void *) -1,
SHGFP_TYPE_CURRENT, folder);
std::cout << "Content-type: text/plain;\n\nReturn value 0x" <<
std::hex << result
<< ", path " << folder << '\n';
}

If I run the executable from the command prompt, it prints "Return
value 0x0, path C:\ProgramData", but if I install the executable as a
CGI handler and browse to its URL, I see "Return value 0x80070003,
path ".

This is true no matter whether the command shell is running as a user,
an administrator, or as NT_AUTHORITY\SYSTEM, and whether I run Apache
as the default NT_AUTHORITY\SYSTEM, or in a local user account.

Using SHGFP_TYPE_DEFAULT instead of SHGFP_TYPE_CURRENT as suggested in
the comments in the Subversion source doesn't make a difference
either.

Most other CSIDL_* known-folder ids do seem to work (I haven't tried
them all). But which one would be a better fit?

Passing the error code 0x80070003 to the FormatMessage function, it
appears to mean "The system cannot find the path specified".

Comp.os.ms-windows.programmer.win32 people, do you have any idea what
are the circumstances under which Vista keeps the location of the
COMMON_APPDATA folder secret, and for goodness' sake why, and what
you're supposed to use instead? I'd like to be able to submit a patch
to the people at Subversion project.

Comp.infosystems.www.servers.ms-windows people, can you help me to
understand what is unusual about the way a process is launched to
handle a CGI request, that could lead to this behaviour?

rcopley@gmail.com wrote:
> I'm cross-posting (or failing that, multiposting) to
> comp.infosystems.www.servers.ms-windows and comp.os.ms-
> windows.programmer.win32, because I don't know whether this is an
> issue with the one, the other, or a mixture of both. I can't cross-
> post it to the Subversion newsgroup, because there isn't one, but if
> this discussion bears fruit I'll summarize it on their wiki.
>
> I have Apache 2.2.11 installed on a stand-alone Windows Vista Ultimate
> SP1 system. I have a CGI perl script which calls "svn.exe".
>
> #!c:/strawberry/perl/bin/perl.exe
> print "Content-type: text/plain;\n\n\n";
> my $status = system "svn --version 2>&1";
> print "svn exited with status $status.";
>
> It works okay at the command line but when called as a CGI script, it
> shows:
> svn: Can't determine the system config path
> svn exited with status 256.
>
> The CGI script also works fine on the Windows XP SP3 systems I've
> tried (Home and Professional Edition).
>
> After looking at the source code for Subversion (see the function
> "svn_config__win_config_path" in "subversion-1.6.1\subversion
> \libsvn_subr\config_win.c"), I've reduced the example to this C++
> program (it's wordy, but it just calls SHGetFolderPath):
>
> #include <iostream>
> #include <ostream>
> #include <windows.h>
> #include <shlobj.h>
> const int SHGFP_TYPE_CURRENT = 0; // Not in my <shlobj.h> for some
> reason
> int main () {
> const int csidl = CSIDL_COMMON_APPDATA;
> char folder [MAX_PATH] = { 0 };
> unsigned result = SHGetFolderPath (0, csidl, (void *) -1,
> SHGFP_TYPE_CURRENT, folder);
> std::cout << "Content-type: text/plain;\n\nReturn value 0x" <<
> std::hex << result
> << ", path " << folder << '\n';
> }
>
> If I run the executable from the command prompt, it prints "Return
> value 0x0, path C:\ProgramData", but if I install the executable as a
> CGI handler and browse to its URL, I see "Return value 0x80070003,
> path ".
>
> This is true no matter whether the command shell is running as a user,
> an administrator, or as NT_AUTHORITY\SYSTEM, and whether I run Apache
> as the default NT_AUTHORITY\SYSTEM, or in a local user account.
>
> Using SHGFP_TYPE_DEFAULT instead of SHGFP_TYPE_CURRENT as suggested in
> the comments in the Subversion source doesn't make a difference
> either.
>
> Most other CSIDL_* known-folder ids do seem to work (I haven't tried
> them all). But which one would be a better fit?
>
> Passing the error code 0x80070003 to the FormatMessage function, it
> appears to mean "The system cannot find the path specified".
>
> Comp.os.ms-windows.programmer.win32 people, do you have any idea what
> are the circumstances under which Vista keeps the location of the
> COMMON_APPDATA folder secret, and for goodness' sake why, and what
> you're supposed to use instead? I'd like to be able to submit a patch
> to the people at Subversion project.
>
> Comp.infosystems.www.servers.ms-windows people, can you help me to
> understand what is unusual about the way a process is launched to
> handle a CGI request, that could lead to this behaviour?

hToken of -1 i for "Default User" which is a template for new user
account, so it's not for the current user nor all users. Try using NULL
instead.

Don't know exactly what's wrong - it should work, but SHGetFolderPath is
considered obsolete in Vista. Try using SHGetKnownFolderPath when only
under Vista or Windows 7.

On Apr 23, 11:34*am, Jaelani <jaeju...@googlemail.com> wrote:
> rcop...@gmail.com wrote:
> > I'm cross-posting (or failing that, multiposting) to
> > comp.infosystems.www.servers.ms-windowsand comp.os.ms-
> > windows.programmer.win32, because I don't know whether this is an
> > issue with the one, the other, or a mixture of both. I can't cross-
> > post it to the Subversion newsgroup, because there isn't one, but if
> > this discussion bears fruit I'll summarize it on their wiki.
>
> > I have Apache 2.2.11 installed on a stand-alone Windows Vista Ultimate
> > SP1 system. I have a CGI perl script which calls "svn.exe".
>
> > #!c:/strawberry/perl/bin/perl.exe
> > print "Content-type: text/plain;\n\n\n";
> > my $status = system "svn --version 2>&1";
> > print "svn exited with status $status.";
>
> > It works okay at the command line but when called as a CGI script, it
> > shows:
> > * * svn: Can't determine the system config path
> > * * svn exited with status 256.
>
> > The CGI script also works fine on the Windows XP SP3 systems I've
> > tried (Home and Professional Edition).
>
> > After looking at the source code for Subversion (see the function
> > "svn_config__win_config_path" in "subversion-1.6.1\subversion
> > \libsvn_subr\config_win.c"), I've reduced the example to this C++
> > program (it's wordy, but it just calls SHGetFolderPath):
>
> > #include <iostream>
> > #include <ostream>
> > #include <windows.h>
> > #include <shlobj.h>
> > const int SHGFP_TYPE_CURRENT = 0; // Not in my <shlobj.h> for some
> > reason
> > int main () {
> > * const int csidl = CSIDL_COMMON_APPDATA;
> > * char folder [MAX_PATH] = { 0 };
> > * unsigned result = SHGetFolderPath (0, csidl, (void *) -1,
> > SHGFP_TYPE_CURRENT, folder);
> > * std::cout << "Content-type: text/plain;\n\nReturn value 0x" <<
> > std::hex << result
> > * * << ", path " << folder << '\n';
> > }
>
> > If I run the executable from the command prompt, it prints "Return
> > value 0x0, path C:\ProgramData", but if I install the executable as a
> > CGI handler and browse to its URL, I see "Return value 0x80070003,
> > path ".
>
> > This is true no matter whether the command shell is running as a user,
> > an administrator, or as NT_AUTHORITY\SYSTEM, and whether I run Apache
> > as the default NT_AUTHORITY\SYSTEM, or in a local user account.
>
> > Using SHGFP_TYPE_DEFAULT instead of SHGFP_TYPE_CURRENT as suggested in
> > the comments in the Subversion source doesn't make a difference
> > either.
>
> > Most other CSIDL_* known-folder ids do seem to work (I haven't tried
> > them all). But which one would be a better fit?
>
> > Passing the error code 0x80070003 to the FormatMessage function, it
> > appears to mean "The system cannot find the path specified".
>
> > Comp.os.ms-windows.programmer.win32 people, do you have any idea what
> > are the circumstances under which Vista keeps the location of the
> > COMMON_APPDATA folder secret, and for goodness' sake why, and what
> > you're supposed to use instead? I'd like to be able to submit a patch
> > to the people at Subversion project.
>
> > Comp.infosystems.www.servers.ms-windowspeople, can you help me to
> > understand what is unusual about the way a process is launched to
> > handle a CGI request, that could lead to this behaviour?
>
> hToken of -1 i for "Default User" which is a template for new user
> account, so it's not for the current user nor all users. Try using NULL
> instead.
>
> Don't know exactly what's wrong - it should work, but SHGetFolderPath is
> considered obsolete in Vista. Try using SHGetKnownFolderPath when only
> under Vista or Windows 7.

Many thanks for your reply.I tried passing NULL instead of -1 for the
hToken argument. I get the same non-result for CSIDL_COMMON_APPDATA.
(For other CSIDLs, different paths are returned depending on the
hToken, as expected.)

Perhaps it's an issue with the toolchain I'm using. I might have more
luck with a Microsoft compiler.

Thanks again,
Buster