It is a vexed issue with Vista/Windows 7.
I found this somewhere on a blog on the web (it may help):
--------------------------
When I'm working to resolve compatibility issues, there are always
multiple options to mitigate. The solution we prefer to use is to update
the code.
A common application code update is this: "my application used to write
files to program files. It felt like as good a place to put it as any
other. It had my application's name on it already, and because my users
were admins, it worked fine. But now I see that this may not be as great
a place to stick things as I once thought, because with UAC even
Administrators run with standard user-like privileges most of the time.
So, where should I put my files instead?"
The answer, as it turns out, is: it depends.
Let's look at the options, and when you might want to choose each.
First, you'll want to use the SHGetKnownFolderPath API function to pull
the function if you are using native code. If you are using managed
code, System.Environment.GetFolderPath will do the trick for you.
FOLDERID_ProgramData /
System.Environment.SpecialFolder.CommonApplicationData
The user would never want to browse here in Explorer, and settings
changed here should affect every user on the machine. The default
location is %systemdrive%\ProgramData, which is a hidden folder, on an
installation of Windows Vista. You'll want to create your directory and
set the ACLs you need at install time.
FOLDERID_Public / FOLDERID_PublicDocuments /
System.Environment.GetEnvironmentVariable("public")
The user would want to browse here in Explorer and double click to open
the file. The default location is %public%, which has explicit links
throughout Explorer, on an installation of Windows Vista. You'll want to
create your directory and set the ACLs you need at install time.
FOLDERID_RoamingAppData /
System.Environment.SpecialFolder.ApplicationData
The user would never want to browse here in Explorer, and settings
changed here should roam with the user. The default location is %appdata
%, which is a hidden folder, on an installation of Windows Vista.
FOLDERID_LocalAppData /
System.Environment.SpecialFolder.LocalApplicationData
The user would never want to browse here in Explorer, and settings
changed here should stay local to the computer. The default location is
%localappdata%, which is a hidden folder, on an installation of Windows
Vista.
FOLDERID_Documents / System.Environment.SpecialFolder.MyDocuments
The user would want to browse here in Explorer and double click to open
the file. The default location is %userprofile%\documents, which has
explicit links throughout Explorer, on an installation of Windows Vista.
Now, you'll note that FOLDERID_Public is kind of the oddball here.
System.Environment.GetFolderPath just calls SHGetFolderPath, which takes
CSIDLs. There is no analogue for %public% here. However, we could have
gone after CSIDL_COMMON_DOCUMENTS (FOLDERID_PublicDocuments) and dropped
things there, but even though we just need to pass 0x2e (46) as the int
argument, we don't offer that. Because we have this subset going, I'd
probably start thinking about using p/invoke if I needed to support
public documents
(http://www.pinvoke.net/default.aspx/shell32.SHGetKnownFolderPath).
----------------
Regards
Andrew
2010/7/8 Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx>:
> On 07/07/10 16:19, el dorado wrote:
>> Hello!
>> I use Postgres 8.4.1 as service, with Windows 7. It seems to me the same situation will take place with Vista.
>>
>> I've notice that in some special cases PG uses folder %APPDATA% for Windows user 'postgres', instead of the PostgreSQL-specific application data folder (f.e., C:\PostgreSQL\8.4\data). It results in some unexpected bugs. There were no such effects in Win XP and 2000.
>
> What files are being created in %APPDATA% for the postgres user? Or
> what's it looking for there that's causing issues?
>
> --
> Craig Ringer
>
> --
> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney 2006 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
