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.
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
Which Vista versions are you installing the product on? Home (basic or premium), Business or Ultimate?
Last edited by Nightwalker83; Jan 2nd, 2009 at 03:05 AM.
when you quote a post could you please do it via the "Reply With Quote" button or if it multiple post click the "''+" button then "Reply With Quote" button.
If this thread is finished with please mark it "Resolved" by selecting "Mark thread resolved" from the "Thread tools" drop-down menu. https://get.cryptobrowser.site/30/4111672
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?
VB/Office Guru™ (AKA: Gangsta Yoda™ ®)
I dont answer coding questions via PM. Please post a thread in the appropriate forum.
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.
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...!
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?
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...
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.
Looks suspicious hmm? I suspect it actually applies to any scenario where you aren't trying to copy the file via Explorer.
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.
Last edited by dilettante; Jan 2nd, 2009 at 12:06 PM.
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.
This is throwing me too. Are you saying now that your program uses CommonAppData and not some ad hoc folder off the drive root?
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.
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...!
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.
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?
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.
I don't understand "elevation" and "legacy installer."
I don't understand "elevation" and "legacy installer."
Can you please explain?
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.
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.
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.
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.
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:
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.
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.
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?
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]
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.
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.
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.
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...
But for now one is probably as good as another if you are creating packages for hobby use, etc.
I am attempting a commercial venture. What is the biggest shortcoming of Inno in this regard?
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?
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.
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?
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.
[RESOLVED] Vista Error 3051
Reply With Quote
Originally Posted by dilettante
