Printable View
My application saves certain variables into an Access 97 database file that I have named with a .sys extension.
Upon installation and launch on some new Vista computers, there is an Error 3051: The Microsoft Jet database engine cannot open the file C:\Bla\Bla.sys
It is already opened exclusively by another user or you need permission to view its data.
Is this possibly caused by the .sys name I chose? Does Vista block access to .sys files?
Yes, .sys is a System file and you may either be experiencing conflicts with .sys or you may be having security permissions issues if the user is not an Administrator.
Thanks, RD
The users are Administrators.
The app works (no error accessing the .sys database file) on any pre-Vista system, and some Vista systems, but not a couple of very new ones.
Do you know of a link to any M$ doc that talks about this new limitation?
Which Vista versions are you installing the product on? Home (basic or premium), Business or Ultimate?
In Vista users need Administrator permissions to access files from that directory. When you install are you right clicking on the exe and selecting "Run as Administrator"? Is the UAC on or off?
Files created off the root of the boot drive (typically C:\) are protected. Most likely users are running afoul of vitualization, and some may be running with UAC disabled.
This is what happens when you break Da Rules.
dilettante, I'm axing someone to show me a path to da Rule...!Quote:
Originally Posted by dilettante
RD, the file is installed in my app's Common Data directory, not the root, or, or...
Nightwalker, two computers having a problem are both Home Premium, one is 64-bit, the other is 32...
The 64 bit Vista system may be a different issue as when you compile you didnt choose a 64 bit platform or dont have 64 bit supporting files. What language was the program written with?
Da rules is ...
http://www.microsoft.com/downloads/d...displaylang=en
http://support.microsoft.com/kb/927387
http://technet.microsoft.com/en-us/l.../cc721929.aspx
My question is distilled down to a straightforward one:
Is there a rule in Vista that disallows accessing a file with a .sys extension?
There are other questions that you guys are axing and I am answering, but I'd like to get an answer to that one, please! I will try to find it in the several links you provided, RD.
My app is installed with Inno and, yes, I do specify 32-bit for all parameters where that is an option. For example:
DefaultDirName={pf32}\Bla Bla", which installs my app into the Program Files (x86) directory on 64-bit systems.
but I install said database into:
Source: "C:\Where I Develop\Database.sys"; DestDir: "{commonappdata}\My Company Name"; Flags: ignoreversion
Because, according to Inno, both 32- and 64-bit apps can use data files in {commonappdata}, as there is no {commonappdata32} parameter.
Although there is a {cf32} parameter for the Common Files directory, which I don't think is where I should put files that are being accessed for read/write...
Thanks for your help so far!
One place to start is the article Common file and registry virtualization issues in Windows Vista.
In there I see:
Looks suspicious hmm? I suspect it actually applies to any scenario where you aren't trying to copy the file via Explorer.Quote:
Error Writing to MyFile.exe
This issue may occur when you perform any of the following actions:
- You create links in virtualized locations.
- You use the Encrypting File System (EFS) to encrypt files.
- You try to view compressed files.
- You use the command prompt to copy an .exe, .sys, or .dll file into a virtualizable location.
A question that occurs to me: Does this application have a manifest? If so, does it contain a <trustInfo> element?
Doing this tells Vista "I know Da Rules, kill me with an error if I break them." Otherwise without this manifest entry Vista will employ AppCompat shims (such as virtualization) to try to help your program survive.
This is throwing me too. Are you saying now that your program uses CommonAppData and not some ad hoc folder off the drive root?Quote:
Originally Posted by Set me As newtype
Yes, the original post was abbreviated.
Where I said, "C:\Bla" should have been CommonAppData\My Company\Bla.sys
Sorry!
No problem. This helps clarify things (scratches head some more).
Do you realize that files/folders that you simply create under CommonAppData default to read-only access for everyone but System, the Administrators group (elevated), and Owner (the creator)?
For something like a shared MDB file the folder needs to be created with full access for the Everyone group (or at least the Users group). This is necessary to allow things like the Jet lockfile (*.ldb file) to be created, updated, and destroyed as well as allowing read, write, and extend on the MDB itself.
I'm not an InnoSetup user so I can't tell you how to do this from there, but that's where it needs to happen.
It sounds like you might be onto something, dillitante...!Quote:
Originally Posted by dilettante
I have Inno set up to require Administrative rights for installation, though... Does that preclude the possibility that this is where the problem lies?
The error occurs immediately when launching after installation (still Administrator).
Even if you didn't tell your InnoSetup to request elevation Vista would sniff it out and determine it to be a legacy installer and request elevation anyway unless you got funky about things like the EXE name it uses. Running as Admin is needed anyway, but won't solve this problem.
You need a step in your setup that creates the folder and sets the permissions on it.
Even if you run the installed program under an admin account, unless you run it "as Admin" (i.e. requesting elevation) it runs as a standard user.
But is all of this something that would only cause a problem on certain, newer, Vista computers?Quote:
Even if you didn't tell your InnoSetup to request elevation Vista would sniff it out and determine it to be a legacy installer and request elevation anyway unless you got funky about things like the EXE name it uses. Running as Admin is needed anyway, but won't solve this problem.
You need a step in your setup that creates the folder and sets the permissions on it.
Even if you run the installed program under an admin account, unless you run it "as Admin" (i.e. requesting elevation) it runs as a standard user.
The app runs fine on several "older" ones...
I don't understand "elevation" and "legacy installer."Quote:
Even if you didn't tell your InnoSetup to request elevation Vista would sniff it out and determine it to be a legacy installer and request elevation anyway unless you got funky about things like the EXE name it uses.
Can you please explain?
Newer Vista systems as compared to older Vista systems or older systems like XP?Quote:
Originally Posted by Set me As newtype
It works on many older Vista systems; just had a problem on a couple of brandie-new ones.
Finally fixed it simply by changing the file extension to something else besides .sys
Thanks for the effort, gents!
In brief terms, "elevation" is how a process obtains administrative access to the system. Even a user in the Administrators group does not have admin rights without elevation if UAC is enabled (as it should almost always be). Microsoft did this because contrarian users insisted on running logged on with an admin account, and this made the system vulnerable to infection by malware. We still have these contrarians, most of them eventually turn UAC off, endangering everyone on the Internet as well as themselves.Quote:
Originally Posted by Set me As newtype
A "legacy installer" is any setup package that does not use Windows Installer technology. VB6's PDW and 3rd party tools like InnoSetup fall into this category. In the future they may not be supported any more.
Inside Windows Vista User Account Control
This may seem like a very long article, but it attempts to sum up the basics of UAC in one place. There are lots of MSDN developer materials on these subject that go into more detail.Quote:
The vast majority of installation programs require administrative rights, so the image loader, which initiates the launch of an executable, includes installer detection code to identify likely legacy installers. Some of the heuristics it uses are as simple as detecting if the image has the words setup, install, or update in its file name or internal version information; more sophisticated ones involve scanning for byte sequences in the executable that are common to third-party installation wrapper utilities.
Basically all programs fall into two categories:
- Legacy.
- UAC aware (once called Vista aware, because the distinction began in Vista).
A program signifies that it is UAC aware via its Application Manifest, which will have a <trustInfo> element that contains a <requestedExecutionLevel> element. This along with the implications of having one or not having one are briefly described in the article above. It includes flow diagrams and screen shots of various Windows dialogs.
The article also goes into administrative approval mode (AAM) users vs. standard users, and Consent vs. over the shoulder (OTS) elevation:
Quote:
Granting a process administrative rights is called elevation. When it’s performed by a standard user account, it’s referred to as an Over the Shoulder (OTS) elevation because it requires the entry of credentials for an account that’s a member of the administrator’s group, something that’s usually completed by another user typing over the shoulder of the standard user. An elevation performed by an AAM user is called a Consent elevation because the user simply has to approve the assignment of his administrative rights.
Thanks dilletante...
Lots to read and try to understand...
This, in particular, troubles me...
So, why is M$ no longer going to support their own PDW? What will replace PDW? Something else they will obsolete in 3 or 4 years?Quote:
A "legacy installer" is any setup package that does not use Windows Installer technology. VB6's PDW and 3rd party tools like InnoSetup fall into this category. In the future they may not be supported any more.
I might just be a contrarian, as I don't like the degree of protection (and especially the resultant obsolescence) forced upon me with Vista... ;)
I know this is not the thread to rant about Vista (I did that elsewhere a while ago), so... [/rant] :bigyello:
It isn't so much the PDW, though people were supposed to stop using it shortly after VB6 came out. I was looking at my VB6 install CDs tonight (dated 1998) and noticed that even in there they were telling you to move to Visual Studio Installer, and provided a link to VSI 1.0 (that is no longer any good).
The problem was that the old scripted setups just are not compatible with the direction they went in "servicing" applications, especially in a managed corporate setting. This is why they came out with the Installer service, the MSI database format of installation package, and new tools like Visual Studio Installer (actually a packager).
You can "move up to 1999" though and download Microsoft Visual Studio Installer 1.1 yet. Even this is ancient, but it is the last version of Microsoft's packager that supports VB6 directly.
After Visual Studio 6.0 there were no new versions created as separate products, though VSI lives on as an embedded tool within the VS.Net versions that followed. There are companies that make commercial packagers that are compatible, and you can always look at MAKEMSI or Windows Installer XML (WiX) toolset.
It can all get pretty overwhelming though.
People use PDW because it was kept in the VB 6.0 package to help VB 4.0 and 5.0 users make the transition. PDW is much like their old Setup Wizard. New users were not supposed to get addicted to it.
Great info, thanks.
So, is the VSI going to become obsolete when other "legacy installers" do?
Is there any reason for me to bother with switching from Inno?
There are two kinds of setup packages: MSIs and legacy installers.
VSI 1.1 is already obsolete as far as Microsoft is concerned, just like VB 6 is, and VB.Net 2001, 2003, 2005, and soon 2008.
However a difference is that VSI 1.1 uses the current Windows Installer API instead of the old Setup API or hand-rolled code. So on a Vista system when you create an MSI package (which is actually a database containing directions, code, and data) VSI 1.1 uses the Windows Installer 4.0 (or 4.5 if you have the update installed) API. When the MSI is installed this is done by the Windows Installer Service 4.0 (or 4.5). Thus Installer is always aware of the OS it runs on and its requirements for keeping track of component use counts, rollback info, etc.
The Setup API is pretty stagnant. Heaven knows what InnoSetup does, but I suspect it's a combination of the Setup API and a lot of hand rolled logic. Setups created by the PDW mostly use the Setup API - which goes way back to DOS days in its earliest form.
But for now one is probably as good as another if you are creating packages for hobby use, etc. Windows Installer packages allow a lot of administrative actions that do not occur in a home or other Workgroup setting. This offers many advantages over legacy installer technologies, the question is whether you need or want these advantages.
Maybe more important is the question of when legacy installers will stop working. Vista SP2? Windows 7?
My own suspicion is they'll work as long as VB6 still runs and maybe after, though you already have to hack around with a PDW or InnoSetup package to make some things work.
Microsoft just wants to say "we told you so" if they ever eliminated support.
I prefer MSIs because of (a.) my customer base which wants MSIs and (b.) a new customer base which wants the capability of non-elevated installs.
Quote:
MSI packages can be marked as not requiring elevated privileges to install, thus allowing a package to install without prompting the user for Administrator credentials.
dilletante,
Thank you again for writing such a thorough and easy-for-a-simpleton-like-me reply!!! I have no edumacation in this stuff, so it's often difficult for me, as I am missing knowledge of the basics.
I think you would make a good teacher, if you were ever so inclined...
I am attempting a commercial venture. What is the biggest shortcoming of Inno in this regard?Quote:
But for now one is probably as good as another if you are creating packages for hobby use, etc.
It has been a little bit of a struggle adapting to Vista (still on-going?), but I have managed, mostly by myself (the .sys question has been the most perplexing issue to date, and as you see I guessed how to fix that myself), so it doesn't seem insurmountable? What am I missing?
As an ignoramous, I can't imagine what they might be... Inno gives me a pretty good bit of control... Can you give me an idea of one or two of the biggest advantages over Inno in terms of administrative actions I might need? Or where I might find a detailed account?Quote:
Windows Installer packages allow a lot of administrative actions that do not occur in a home or other Workgroup setting. This offers many advantages over legacy installer technologies, the question is whether you need or want these advantages.
I hope these questions and answers might help others, too. THANK YOU.
If you look at my previous post there was a link to a Wikipedia article that describes some of the features Windows Installer setup offers over older forms. Part 2.3 and all of part 3 cover many of these. Part 6 of that article goes into some of the disadvantages.
The advantages become more important in corporate settings where application installation and updating is centrally managed.