Where to put an ini file on Win with write access for all users?

[Jim Bufalini]

Hi Tiemo

> I have an ini file, which should be accessed read/write by every user
> on the
> machine, so it can't be in the user dir.
> 
> I choose specialfolderpath("35") & "\" & myFolder which is on XP:
> C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\myFolder and
> on
> Vista C:\ProgramData\myFolder
> 
> On a XP machine I don't have write access to this ini file with a
> different
> user, as having created the file. I could catch the error and tell the
> user,
> he should give permissions to that file for all users. Not nice, but a
> chance. On Vista I don't get an error when trying to write to that file
> with
> a different user, Vista just virtualises the ini file in the user dir
> of the
> other user and from now on I have an ini file for each user, what is a
> mess,
> because there are common options, which should be the same for all
> users.
> 
> Any coaching how to handle this correctly very appreciated!

Ini files are considered a legacy file structure by Vista. Vista virtualizes
anything it considers legacy under an identical directory tree under each
user's virtualstore directory. Use the registry instead to store ini kind of
information. The registry was originally dreamed up to replace ini files and
then immediately expanded from there.

This is why it is so, so, so important that Rev gets around to updating the
SQLite engine embedded in the dbsqlite.dll driver. The SQLite engine shipped
with Rev is pre-Vista and not forward compatible. As soon as you create a
data file, Vista identifies both your app and data file as legacy and
virtualizes the database file by making a copy of it. Everything seems fine
until you close your app and launch it again and try to read updated data
from the previous session. It appears to have all disappeared. What has
actually happened is all the writes went to the virtualized file(s) - one
for each user, and you have a mess. This virtualization doesn't happen with
later versions of the SQLite engine.

Jim Bufalini