Very troubling problems running on Vista Beta

  • Thread starter Thread starter Dan
  • Start date Start date
D

Dan

If this is the wrong NG to post this please point me to the correct place...

I've had a few people try my VB app on Vista Beta installations. One of the
problems I'm seeing is that my app can't seem to write information to the
installation folder. Yet no error is being raised when it tries to write
out information. As far as the app is concerned there's no problem. I
noticed this when people who tested the app couldn't find the app's log
file. When they send me directory listings of everything in the
installation folder it was clear that there was nothing present that wasn't
put there by the installation utility.

This really has me troubled. I don't have a Vista Beta installation of my
own to test with. My app writes both a log file and the user's data file to
the installation folder by default. Not only that, my app frequently needs
to be updated. I handle this through a utility that downloads the newer
..exe and deletes the old. If it can't download and write out the new .exe
then my app can't be updated! I can handle (though not be happy with) the
need to write both the log and data file to the \Documents and
Settings\(user name)\Application Data\ folder if Microsoft forces me to do
so. But if the app can't be updated I'm really in a world of hurt.

Has anyone else encountered this problem? Anyone know why an app would not
be allowed to write data to its installation folder yet not get an error
from Vista when it isn't allowed to do so?
 
It could be related to File (and Registry) Virtualization.

Quote from
http://windowsconnected.com/blogs/jerry/archive/2005/12/19/86.aspx :

When an application attempts to do something "bad" like write to an INI file
like "C:\Program Files\PoorlyBehavedApp\Options.ini", Windows will detect
that the user's token does not grant them access to save to that location.
Instead, it will copy the existing file (if it already exists) to
"C:\Users\<your_account>\AppData\Local\VirtualStore\Program
Files\PoorlyBehavedApp\Options.ini". It will then allow the write operation
to succeed to this new file in the VirtualStore folder. Subsequent read
operations for that file will always preferentially use the copy in the
VirtualStore. Here's a simplified flow chart outlining these read and write
operations.
 
Dan said:
If this is the wrong NG to post this please point me to the correct
place...

I've had a few people try my VB app on Vista Beta installations. One of
the problems I'm seeing is that my app can't seem to write information to
the installation folder. Yet no error is being raised when it tries to
write out information. As far as the app is concerned there's no problem.
I noticed this when people who tested the app couldn't find the app's log file. When they send me directory listings of everything in the installation folder it was clear that there was nothing present that wasn't put there by the installation utility.

This really has me troubled. I don't have a Vista Beta installation of my
own to test with. My app writes both a log file and the user's data file
to the installation folder by default. Not only that, my app frequently
needs to be updated. I handle this through a utility that downloads the
newer .exe and deletes the old. If it can't download and write out the
new .exe then my app can't be updated! I can handle (though not be happy
with) the need to write both the log and data file to the \Documents and
Settings\(user name)\Application Data\ folder if Microsoft forces me to
do so. But if the app can't be updated I'm really in a world of hurt.

Has anyone else encountered this problem? Anyone know why an app would
not be allowed to write data to its installation folder yet not get an
error from Vista when it isn't allowed to do so?
Click to expand...

Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.

I don't know about application updates - but I imagine that MS have
something in place for this scenario too.

It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.
 
I don't know about application updates - but I imagine that MS have
something in place for this scenario too.
Click to expand...

You can do this using Visual Studio 2005, and the "Publish" settings of your
application. You can configure your applications to look on a web server to
download the latest build of your product - it's really easy to set up, and
with Windows Server 2003 running with IIS, work's an absolute treat.
It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.
Click to expand...

Couldn't have said it better myself :o) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with. If you
check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.

All the best :o)

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---
 
Is it that thing called Click Once? I remember Microsoft pushing it a lot at
PDC 2003.
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta

Zack Whittaker (R2 Mentor) said:
I don't know about application updates - but I imagine that MS have
something in place for this scenario too.
Click to expand...

You can do this using Visual Studio 2005, and the "Publish" settings of
your application. You can configure your applications to look on a web
server to download the latest build of your product - it's really easy to
set up, and with Windows Server 2003 running with IIS, work's an absolute
treat.
It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to
write to an application's own folder, ergo an application loaded by them
has the same restriction.
Click to expand...

Couldn't have said it better myself :o) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with. If
you check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.

All the best :o)

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and
not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---
Click to expand...
 
Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.



I sure hope this can be disabled - what a stupid idea.

--

Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/

Please reply to the newsgroups so all can participate.
 
Steve Foster said:
It's all part of the UAP/LUA stuff - since users generally should not be
running with administrative privileges, they don't have the right to write
to an application's own folder, ergo an application loaded by them has the
same restriction.
Click to expand...

Oh yes, we can't let applications write to their own folder. Why if we let
them do that... Actually, I don't see much reason why that should be a
problem. Frankly, I don't see how it makes the system more secure. Just
more difficult for developers like me. Sigh...
 
Zack Whittaker (R2 Mentor) said:
You can do this using Visual Studio 2005, and the "Publish" settings of
your application. You can configure your applications to look on a web
server to download the latest build of your product - it's really easy to
set up, and with Windows Server 2003 running with IIS, work's an absolute
treat.
Click to expand...

Unfortunately I'm not developing with .NET. But how does this help even if
I were? Are you saying the "publish" settings of my .NET app causes Vista
to allow it access to write to the installation folder?
Couldn't have said it better myself :o) So yeh, if you can get TechNet or
TechNet Plus, you can then get yourself a copy of Vista to test with.
Click to expand...

Unfortunately, I don't have a spare PC to install it to. I guess I'll have
to cough up the money for a new development machine just to test Vista on.
check out the UAP Guidelines,
http://www.microsoft.com/technet/windowsvista/evaluate/feat/uaprot.mspx -
you might find that useful.
Click to expand...

Thanks! I'll have a look.
 
Randy Birch said:
Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.

I sure hope this can be disabled - what a stupid idea.
Click to expand...

Which is stupid? The idea of turning it off or the idea that it needs to be
turned off? I honestly don't see how allowing an application that the user
installed to write to the installation folder is a problem.
 
I honestly don't see how allowing an application that the user
installed to write to the installation folder is a problem.
Click to expand...

Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.

--

Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/

Please reply to the newsgroups so all can participate.
 
Kinda yeh... I didn't want to say it because it's not directly that as
such... but weaves into it yeh.

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---
Andre Da Costa said:
Is it that thing called Click Once? I remember Microsoft pushing it a lot
at PDC 2003.
--
--
Andre
Windows Connect | http://www.windowsconnected.com
Extended64 | http://www.extended64.com
Blog | http://www.extended64.com/blogs/andre
http://spaces.msn.com/members/adacosta
Click to expand...
 
Well, it depends on what you're devloping in. Most software building
applications have an "auto-update" feature in it... so it just depends on
whether you can find it or not.

--
Zack Whittaker
Microsoft Beta (Windows Server R2 Beta Mentor)
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: http://msblog.resdev.net
» ZackNET Forum: www.zacknet.co.uk/forum
» VistaBase: www.zacknet.co.uk/vistabase
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, mother or cat. Let's be clear on that one!


--- Original message follows ---
 
Randy said:
Vista has mechanisms to automatically redirect writes to an application
folder to a folder within the user's own space. So you should find the log
files have been auto-relocated to somewhere deep within \Users\<username>.



I sure hope this can be disabled - what a stupid idea.
Click to expand...

Well, applications saving user-specific information in the application
folder is also a stupid idea. That's what the users profile folder space
is for.

Applications that assume they can do whatever they like is *so* Win31...

Really, this concept is not new - it's been around since NT4 and probably
even NT3. In a sense, it would almost be better simply to fail the writes,
except that application vendors would carry on with the current lazy
answer "make your users local administrators", rather than getting with
the program and making their applications well-behaved. At least MS are
trying to provide a graceful (ish) solution that lets applications work,
without forcing the administrative privilege escalation.
 
Dan said:
Which is stupid? The idea of turning it off or the idea that it needs to
be turned off? I honestly don't see how allowing an application that the
user installed to write to the installation folder is a problem.
Click to expand...

Then why not set the ACLs accordingly during installation - 99% of
applications that want to write to their own folder don't do this, they
simply expect that users would be local administrators (and indeed if you
call Tech Support the response is "oh yes, make users local
administrators").

It's this abject failure on the part of developers that UAP is trying to
help with.
 
Randy said:
Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.
Click to expand...

Why should the application have the privilege of writing to its' own
folder? It runs in the context of the user account that starts it, and
inherits their permissions. Users should not generally have privileges to
write to installation folders, only their own profile space. Ergo, that's
where applications should be storing user data.
 
Dan said:
Oh yes, we can't let applications write to their own folder. Why if we
let them do that... Actually, I don't see much reason why that should be
a problem. Frankly, I don't see how it makes the system more secure.
Just more difficult for developers like me. Sigh...
Click to expand...

I expect that you use HKLM to store user information too, rather than HKCU
when using the registry, right?
 
Randy Birch said:
Exactly. My remark was aimed at the concept that the OS would prevent an
installed app from writing to its own folder, ini file or whatever, and
transparently relocate that file to another location.
Click to expand...

I completely agree!
 
Back
Top