Details on the 1.7 Installer fail as non-admin[NOTED]

Hi Lee,

Didn’t see your reply on this due to own business until today.

I’ve just recreated the scenario, also trying to help a bit, and still get the solid fail. Off the top, I wonder if you’re not seeing this because you’re not deleting the Program Files/Scrivener folder from a previous install?

I’ve attached a picture, where permission is refused to write in the normal Program Files directory. Setup is as follows:

  • deinstall what was now 1.8; no problems
  • delete, not just re-name, the Program Files/Scrivener directory, which had the aspells and a few other things this time. Now Program Files is clean.
  • assure User is non-adminstrator, and reboot to be doubly sure it fully takes.
  • using regedit, clear HKCU and HKLM keys for Scrivener. I left the Aspell ones. I had to run regedit as adminstrator to be allowed to clear keys from HKLM.
  • attempt to install Scrivener 1.7. Get the fail shortly into the process, as in the picture, unable to write in Program Files to create the Scrivener directory.

By the way, I’m also seeing the informed-of-update-available, but no-updater-button from the Update dialog. I was successful at manually running the updater from inside Program Files as someone posted.

Machine here is Windows 7 SP 1 as released through Windows Update just this week, always kept patched to the max on everything. Dual cpu, 3GB RAM, lots of hard disk.

I just checked the permissions on Program Files, which are pretty wierd indeed, but I think correct, as Trusted Installer has eventually full permissions via a Special permission. That fact is invisible unless you open the special permission.

Hope useful, and I am really getting into some uses of Scrivener, so again will be posting lists of the small user interface gotchas. Also one related to the Zoom issues: the preview is that copy-pasted text presents the wrong font size from Scrivener to Word (!). There are other things around this, so will post separately. But it is a great effort continuing.

Best,
Clive

Lee, I tried some other things, had to send the first report to be able to do it.

  • I tried turning UAC full off (bottom of the slider), as had read this helped some similar issues. But, no go - did not help at all, with same symptoms resulting.

  • I tried creating the Scrivener folder in Program Files, then installing. Fail, same again - I thought because the examined security permissions of this new folder did not include the Special permissions block.

  • So I removed that folder, installed Scrivener as administrator, and deinstalled. The resulting PF/Scrivener folder did have the Special permissions. However, relogged in set to standard user, the installer again failed in the usual way - no permissions.

Something is up with this, but I think it takes more to find it. Hope I’ve helped avoid a few false trails. I will now re-login as Adminstrator, and reinstall, then manually upgrade to 1.8, and use Scrivener :wink:

Best again,
Clive
who’s not an Oz-ite, but has known a few :wink:

The Program Files (and Program Files x86 on 64-bit installations) directory is a protected folder in Windows Vista and 7. The only way to modify any file or folder within (be it adding, deleting, renaming, or moving) is with administrator privileges.

Thanks, MalignantCarp (nice name…). I do know all that.

The detail is to help Lee locate where there shouldn’t be a problem – that the administration-free mode of the installer isn’t working here, as in the picture.

There should be no need for anyone ever to modify the permissions on the Program Files folder; and they are unusual for security reasons. The TrustedInstaller permissions are buried and special, to allow, well, installers, and in this case they look fine - installers should have all privileges, including the failing one, to write. Possibly the issue has to do with how or when the privileges are being requested.

Interested what this will turn out to be, anyway.

Regards,
Clive

Is the issue that the installer isn’t bringing up the UAC prompt or that it can’t install to Program Files?

To the best of my knowledge, there’s no way around this problem without UAC. An installer must be run by or as an administrator (whether through right-click > Run as Administrator or through UAC prompt) in order to install to Program Files, hence the warning and installation failure.

Regards,
Carp

Actually, that’s a good question about the UAC prompt, and related machinations.

Lee’s expressed purpose for this release was that it be able to install from an ordinary user account, a very fortunate idea.

Therefore I tested it carefully for this – particularly since recently deciding my own years of experience were no defense (!) against any of today’s sophisticated attacks, given they get past the decent stack of protection on the machine; thus that I should do the right thing and operate as non-administrator.

So:

  • I don’t think a UAC prompt should be needed. The point is that a Standard user should be able to make the install, as Lee wants.

  • The fact is, to answer your question, that no UAC prompt appears. Also, the experiment of turning UAC down to the apparently promptless level bears no fruit. I still get a basic lack-of-write-perms error, while the Special security permissions in fact allow Write as well as anything else in the book. My understanding is that an Installer has the possibility to use this Special permission; and in fact it’s the only Write permission I could find for the Program Files folder - just correct, for the intended security.

  • Now, how do you make it do that, the installer? This looks rather intricate, in two decent links I found; one contained in the other, and which goes to an MS person’s weblog:
    == http://stackoverflow.com/questions/4080131/how-to-make-a-setup-work-for-limited-non-admin-users
    == http://blogs.msdn.com/b/rflaming/archive/2006/09/30/778690.aspx

What’s going off the track at present? It might be as simple as the need for a manifest as explained at bottom of the first link. Or…

By the way, I find running as a non-admin user to be fine for operating almost any software. It’s not fine as far as most software’s installers. They typically don’t implement what Lee is arranging, and raise a UAC prompt at best. And if I am so foolish as to respond to that UAC prompt by password enabling a separate Administrator account as it offers, I am likely to find configuration for the installed software appearing under the other user’s account, thus a failed install. Or worse: files installed in the Program Files area are owned by that other user, and can’t be seen or used! I make a habit of raising to Adminstrator, and logging out/logging in before installations, but that is just what we should for convenience and consideration of safety avoid.

All things considered, then, as usual Lee and team are doing just the right thing, at least I think so. Especially for a package that will be a friend to many who are experts at other things than software machinations. Many benefits to be reaped from him doing this, not least in support down the road.

Best to each,
Clive

Just one more thing. It occurs to me that even if this install-as-Standard User ability was working, you might be right that there would be a UAC prompt. It just wouldn’t ask for any additional privileges.

That would be the safe way – I don’t know if it is the MS way…

In that case, it’s even more significant, as a clue, that I didn’t get any UAC prompt – just the permissions fail in attempting to add or modify a Scrivener folder within Program Files.

C.

OK, now I understand you better.

The current installer works fine for anything but Program Files, so this is clearly a rights issue. I suspect that there is no way to make a standard-user-run installer install to Program Files without UAC elevation, thus users should be advised to install elsewhere (I install to C:\Apps, for example) or else a UAC prompt will be required if a user tries to install somewhere where he or she has no privileges (e.g., Program Files). If Lee can check the privileges prior to installation and use a UAC prompt only when necessary, that would seem to me to be the best in-between.

You are quite right that UAC shouldn’t be needed, but in my experience, just about every installer (certainly every game and expensive application I have installed) throws up the UAC prompt.

Yes you are correct there is no way around the UAC prompts - I’ve tried :slight_smile:

I will look at working a prompt into the installer to detect if they have insufficient permissions to install to a particular location. I will also be sure to make note in the official installer notes that whilst an install is possible without Admin rights - it may mean that if you don’t have permission to the Program Files or Program Files(x86) directories, then you’ll need to install elsewhere i.e. c:\users\user\PERSONAL FOLDER?

Thanks for bringing this to light.
Lee

All right, I couldn’t believe the situation, but I was wrong.

I parsed through enough of the endless articles-in-a-chain from guy apparently on the MS Installer team, on the link above. And indeed, you can’t write Standard User-installable applications into the Program Files folder area. He says.

I think he is saying you can do Standard User installs without a UAC prompt - the flip bit 3 talk below.

His surrounding thesis sounds like the very worst sort of corp-speak and ms-ism. So we will leave all that.

Here are his instructions. They explain why I caught some odd-seeming install behaviour on other programs (not the ones that made downright errors). They were installing to their own folder in the User’s Application Data area, and that is what is suggested here to do. In fact even Google does it, for Chrome.

He doesn’t want you to install for all users, if his syntax is strange about that.

This comes from here: Post 17. Beneath all his boilerplate listing every article, in every article. My goodness.

Best fortune,
Clive

Thanks Clive. I think I’ve learned most of this the hard way; however, I not seen point 5 before:

Thanks mate, I take a look at this flipping of bits.
Lee

Good man.

Flippy bits, yes; and will want to remember about writing the app to the user LocalAppDataFolder area, as the fault-out I was getting concerns writing to Program Files, which I now agree MS has made it so you can’t.

Take care, Lee. This has to be the worst of the kinds of stuff :wink:

Carpe diem, metaCarpish :wink:

C.