Prev: Sun IDM resources | Multiple Locations
Next: Any mde restrictions for queries?
From: jwither on 28 Jun 2010 07:13

On my computer, the installer crashed on the Hatten font
installation, as recorded by the error in the installation log,
causing the installation to not be completed. Non-completion
of the installation meant that the registration was not attempted.

Removing or correcting the Hatten font line in the installation
script allowed the script to proceed to registration.

From memory, the problem was that the installation script
incorrectly validated the file size if a newer version of the
font was already installed.


(david)


"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
news:Xns9DA3B50045FBBf99a49ed1d0c49c5bbb2(a)74.209.136.94...
> Tony Toews <ttoews(a)telusplanet.net> wrote in
> news:enrc269djn5246hki3qbr7ctqphpha229v(a)4ax.com:
>
>> And other than the known A97 Hatten font problem I've
>> never had any problems.
>
> Aiee! There is no such thing as a Hatten font problem. There was
> nothing wrong with that font, and the font didn't cause the issue.
> But if the install process found the Hatten font missing, it would
> trigger a reinstall that would properly register everything.
>
> In other words, renaming the font was just a simple way to trigger
> the fix. It wasn't the fix itself, because there was nothing wrong
> with the font in the first place.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/


From: Douglas J. Steele on 28 Jun 2010 07:59
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
news:Xns9DA3B5631A91f99a49ed1d0c49c5bbb2(a)74.209.136.94...
> "Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in
> news:i05222$9e4$1(a)news.eternal-september.org:
>
>> "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message
>> news:Xns9DA2C1CA2AE96f99a49ed1d0c49c5bbb2(a)74.209.136.94...
>>> "Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in
>>> news:i02ocj$hmg$1(a)news.eternal-september.org:
>>>
>>>> "Tony Toews" <ttoews(a)telusplanet.net> wrote in message
>>>> news:ion926p7tuvhm54ia4nf2t3lm5f915ajls(a)4ax.com...
>>>
>>>>> However regular users can't update any files
>>>>> in the Windows System folder.
>>>>
>>>> Don't believe that's generally the case. Definitely I can write
>>>> to that folder (and given how locked down our machines are, I
>>>> can't imagine that we would have relaxed built-in security rules
>>>> anywhere! And given that a System.ldb file is opened whenever
>>>> you're using the System.mdw file, it really wouldn't make sense
>>>> that the file would be written to a write-protected folder.
>>>
>>> That's odd, as the default permissions on the Windows folder have
>>> been read-only for users starting with Win2000. Power Users have
>>> modify permission. Are you sure you're not running as a member of
>>> the Power Users group?
>>
>> Positive.
>>
>> It's possible that they perverted the default permissions, but I'd
>> be extremely surprised, since generally we tighten up security,
>> not loosen it, in our environment. When I get back to the office
>> on Monday, I'll try and remember to check the permissions on the
>> folder.
>
> I'm pretty sure that running in a domain environment you're running
> as a user and just because you're in a domain you don't get more
> permissions than you'd get running as an individual. The same
> read-only limitations apply to the root of C: and to the programs
> folder, BTW, and this has been so since the introduction of Windows
> 2000, which was the first version of Windows to move the user
> profiles out of the Windows folder in order that the Windows folder
> could be properly locked down without having special permissions on
> the profiles folder.

Okay, running Windows XP Professional, SP2 in a domain, I cannot create
folders on the C: drive, but I can create folders in the C:\Windows folder
and the C:\Windows\System32 folder.

Looking at the Advanced Security Settings for both C:\Windows and
C:\Windows\System32, the Users group has Read & Execute on "This folder,
subfolders and files", and has Modify on "This folder only" and "Files
only", all of them "<not inherited>"

On the other hand, the Users group only has Read & Execute on "The Folder,
subfolders and files" for the C: drive itself.

--
Doug Steele, Microsoft Access MVP
http://www.AccessMVP.com/DJSteele
Co-author: Access 2010 Solutions, published by Wiley
(no e-mails, please!)



From: David W. Fenton on 28 Jun 2010 15:54
"jwither" <jwither(a)sxder4kmju.com> wrote in
news:Q62dnY_Rd9NTHrXRnZ2dnUVZ_vSdnZ2d(a)westnet.com.au:

> From memory, the problem was that the installation script
> incorrectly validated the file size if a newer version of the
> font was already installed.

This contradicts what I recall Michael Kaplan having explained to us
about the situation.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 28 Jun 2010 15:58
"Douglas J. Steele" <NOSPAM_djsteele(a)NOSPAM_gmail.com> wrote in
news:i0a2rs$eof$1(a)news.eternal-september.org:

> Looking at the Advanced Security Settings for both C:\Windows and
> C:\Windows\System32, the Users group has Read & Execute on "This
> folder, subfolders and files", and has Modify on "This folder
> only" and "Files only", all of them "<not inherited>"

All of the permissions in my non-domain C:/Users are not inherited,
but the modify permissions are not there. I wonder if that's a
customization on the part of your sysadmins.

> On the other hand, the Users group only has Read & Execute on
> "The Folder, subfolders and files" for the C: drive itself.

This is the same permission as I see on C:\Windows on a standalone
PC, and it's what I'm accustomed to seeing since Win2000. It's also
the permissions I assume for anything I do with Access.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: Sun IDM resources | Multiple Locations
Next: Any mde restrictions for queries?