Interesting Issue

[Simon Dean]

Hi,

We are installing some updated software where I work, Sunrise Enterprise.

We have been experiencing some random issues, never quite the same.

Now we have had two versions of the software, and client software,
Client32, refers to an INI file in the software folder to find the path
of the database configuration file.

The path was "Enterprise 5.0". There is now an "Enterprise 6.0" and to
ensure no mismatches, "Enterprise 5.0" was renamed "Enterprise 5.0 OLD".

Now, some of these paths weren't updated correctly. So we fixed this on
Windows XP by modifying the INI file. And that then just worked.

Windows Vista on the otherhand...

We change the INI file using Notepad, everything looks fine, but the
program does not appear to pick up the change. We know this, because it
does not provide the expected login screen. If we restore the Enterprise
5.0 folder on the network, then everything kicks into life.

Removing the 5.0 folder again, and Vista breaks.

We check the INI files in Notepad again, and they all point to
Enterprise 6.0. We also check the registry, and there is no reference to
Enterprise 5.0.

There's something we're obviously missing.

I would be very tempted to query whether when querying the INI file,
Vista is reporting an outdated "shadow copy" of the file, for some reason.

However if I log into the Vista PC as another user, or even Run as
Administrator, then the software works and correctly picks up the
Enterprise 6.0 folder.

Im very confused.

Do you have any thoughts as to what might be happening?

Thanks
Simon

 

[Charlie Tame]

Hi,

We are installing some updated software where I work, Sunrise Enterprise.

We have been experiencing some random issues, never quite the same.

Now we have had two versions of the software, and client software,
Client32, refers to an INI file in the software folder to find the path
of the database configuration file.

The path was "Enterprise 5.0". There is now an "Enterprise 6.0" and to
ensure no mismatches, "Enterprise 5.0" was renamed "Enterprise 5.0 OLD".

Now, some of these paths weren't updated correctly. So we fixed this on
Windows XP by modifying the INI file. And that then just worked.

Windows Vista on the otherhand...

We change the INI file using Notepad, everything looks fine, but the
program does not appear to pick up the change. We know this, because it
does not provide the expected login screen. If we restore the Enterprise
5.0 folder on the network, then everything kicks into life.

Removing the 5.0 folder again, and Vista breaks.

We check the INI files in Notepad again, and they all point to
Enterprise 6.0. We also check the registry, and there is no reference to
Enterprise 5.0.

There's something we're obviously missing.

I would be very tempted to query whether when querying the INI file,
Vista is reporting an outdated "shadow copy" of the file, for some reason.

However if I log into the Vista PC as another user, or even Run as
Administrator, then the software works and correctly picks up the
Enterprise 6.0 folder.

Im very confused.

Do you have any thoughts as to what might be happening?

Thanks
Simon

Very much a guess but have you considered "Permissions". Maybe something
in the network is not letting the Vista machine read the file, or maybe
Vista regards the file as somehow unacceptable?

 

[Simon Dean]

Very much a guess but have you considered "Permissions". Maybe something
in the network is not letting the Vista machine read the file, or maybe
Vista regards the file as somehow unacceptable?

The INI file references a CFG on the server.

The INI file is locally based. The local users are set as local
administrators on the local machine. Security and permission for folders
has been checked a number of times.

The CFG file of databases on the server is correct as it works with
Windows XP machines.

The INI files must be correct because logging in as a different user on
the same Vista machine is good.

There isn't a problem accessing the CFG on the server, because the same
troublesome user can run another program that references a different INI
but the same CFG successfully.

This leads me to believe there is some stale path set somewhere under
that specific user - whether physically under UserData somewhere or in
Registry - But I cannot find this. This then leads me to wonder whether
the INI file is being "cached" in someway for this particular user?

There are no other things that I can possibly think of.

 

[Charlie Tame]

The INI file references a CFG on the server.

The INI file is locally based. The local users are set as local
administrators on the local machine. Security and permission for folders
has been checked a number of times.

The CFG file of databases on the server is correct as it works with
Windows XP machines.

The INI files must be correct because logging in as a different user on
the same Vista machine is good.

There isn't a problem accessing the CFG on the server, because the same
troublesome user can run another program that references a different INI
but the same CFG successfully.

This leads me to believe there is some stale path set somewhere under
that specific user - whether physically under UserData somewhere or in
Registry - But I cannot find this. This then leads me to wonder whether
the INI file is being "cached" in someway for this particular user?

There are no other things that I can possibly think of.

Check the shortcut to see if there's some absolute path in it?

Sorry if this is no help but now 2 of us are confused

 

[Andrew McLaren]

Now we have had two versions of the software, and client software,
Client32, refers to an INI file in the software folder to find the path of
the database configuration file.
We change the INI file using Notepad, everything looks fine, but the
program does not appear to pick up the change. We know this, because it
does not provide the expected login screen. If we restore the Enterprise
5.0 folder on the network, then everything kicks into life.
Do you have any thoughts as to what might be happening?

Hi Simon

Is the INI fle under the "C:\Program Files" directory?

If so, you may be seeing a side-effect of file system virtualisation:

Common file and registry virtualization issues in Windows Vista
http://support.microsoft.com/kb/927387/en-us

For security reasons, Vista does not like having user-edited files under the
%ProgramFiles% directory. They should be kept under %AppData% or similar
location. A future, Vista-compatible version of the software in question
will probably fix this issue. In the meantime, look for the INI file in the
virtualised location, %userprofile%\AppData\Local\VirtualStore.

Hope it helps,

 

[Charlie Tame]

Hi Simon

Is the INI fle under the "C:\Program Files" directory?

If so, you may be seeing a side-effect of file system virtualisation:

Common file and registry virtualization issues in Windows Vista
http://support.microsoft.com/kb/927387/en-us

For security reasons, Vista does not like having user-edited files under the
%ProgramFiles% directory. They should be kept under %AppData% or similar
location. A future, Vista-compatible version of the software in question
will probably fix this issue. In the meantime, look for the INI file in the
virtualised location, %userprofile%\AppData\Local\VirtualStore.

Hope it helps,

So if being "User editable" is the cause how come other user's versions
of the INI are accepted. Is it because that "User" may not be the one
who edited the file?


This appears to be a problem that exhibits itself in a pseudo random
manner making diagnosis a real PITA.

 

[Andrew McLaren]

So if being "User editable" is the cause how come other user's versions of
the INI are accepted.

No idea if the 927387 issue is the correct or total explanation for what the
OP is seeing. It just seemed a possibility worth investigating.

If user 1 edits the foo.ini file and saves the changes, the updated version
might really be saved in:
C:\Users\User1\AppData\Local\VirtualStore\foo.ini

When User 1 looks at the updated foo.ini file, it *looks* like it is in
C:\Program Files\<some app>. But it isn't. If User 2 looks at C:\Program
Files\<some app>\foo.ini, they see a different file, without the updates
made by User 1; albeit apparently in the same location.

Weird behaviour of this kind has been reported by previous posters to this
newsgroup, and it was isolated to a side effect of "Program Files" directory
virtualisation described in 927387.

 

[Simon Dean]

Hi Simon

Is the INI fle under the "C:\Program Files" directory?

If so, you may be seeing a side-effect of file system virtualisation:

Common file and registry virtualization issues in Windows Vista
http://support.microsoft.com/kb/927387/en-us

For security reasons, Vista does not like having user-edited files under the
%ProgramFiles% directory. They should be kept under %AppData% or similar
location. A future, Vista-compatible version of the software in question
will probably fix this issue. In the meantime, look for the INI file in the
virtualised location, %userprofile%\AppData\Local\VirtualStore.

Hope it helps,

Buy that man a drink.

Spot on.

Knew it had to be something like this, but I couldn't find it or explain
it. So thank you very much for your detailed reply.

Much appreciated.

Simon