Ted and others with interest, I'm still hoping for a simple solution that applies across VISTA versions without requiring an intolerable methodology change or an OS hack.
The methodology I use is simple and well tested (until this discovery), and seems to be the same as you're using: - user installs application into c:\product - if the apps 'auto updates' option is enabled, the app checks the inet server for updates during startup, looking for a higher numbered productxxxxx.zip file. If one exists, it FTP downloads the file into c:\product and unzips it - in the next product startup, the loader finds the higher numbered exe and runs it - fallback is to delete the higher numbered exe I had originally targeted PROGRAM FILES for the installation, but ran into problems with other applications that my app might use which choke on paths with embedded blanks (e.g. pkzip and freezip at the time, but recall other example since), so I decided to K.I.S.S. and require a simple c:\product folder for the product's installation, with a sub-folder structure under it. Works fine and no problems with embedded blanks to deal with. Note that I don't deal with big corps, just small businesses (deliberately), and in these environments C:\PRODUCT is not a problem as they don't have that many apps in the first place. Also because these are small businesses, it's not a problem getting their ADMIN to tweak the system during the installation process, it's just that I don't know what that action should be. On the VISTA Home machine I tried some rights tweaks, but to no avail. For one thing, I noticed that the owner of the machine in question has Admin rights, but there is no way to logon as Admin, only as username with admin rights. Sounds like it shouldn't make a difference, but it may be the problem. Another wild card on this particular machine is Norton, which apparently is running but "disabled" in that the subscription hasn't been paid, so it's running with old definitions - but running nevertheless. But my suspicion is that it's not Norton who is erasing the downloaded file, but VISTA, and that seems to have been proved by observing similar behavior with VISTA Home Premium in another installation (where downloads into C: and C:\PROGRAM FILES disappear after download completes, but downloads into C:\PRODUCT are okay). Bill > > The FTP is going into c:\product, not c: > > > > On the Vista Home Premium tested with, this isn't > happening, just with > > Home Basic. > > > > I'd also like to have some guidance on what the current best > practice is. > > We're supporting a 20-year-old FoxPro program that's grown > through FoxBase and Fox 2.x and VFP and is both stable and > mature. We're using the typical "loader" program to determine > if there are updates by looking on the network and download > the update and chaining to that one. We're running in > /Program Files, but that's becoming a hostile environment; > our most secure clients have had to specially-configure our > directory to allow user read-write. > > What's the most efficient (cheap in time and cost) means of > configuring this app to work with the new OS restrictions? > > > -- > Ted Roche _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
