Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread ElevateDB - Playing well with Vista
Fri, Apr 20 2007 10:25 PMPermanent Link

"Lance R"
Tim,

There's a sort of chicken / egg thing with permissions that would be nice to
address.

Please read in the irony and distain in my "voice", but its something to
consider.

"Uncle Bill" says apps should go into Program Files.  And...  By the way...
Anything in Program Files is Read Only......  Not a problem.  I'll put the
ElevateDB server in program files because its just an app.

"Uncle Bill" says data should go into the User's sub folders (or Documents
and Settings\ for XP).  This is read/write.   Not a problem.  I'll put the
ElevateDB data in C:\Documents and Settings\All Users\Application
Data\ElevateDBData so that server only deals with ONE set of data and can
serve no matter which user logs in.    And since I still need to deal with a
temp folder, I'll nest the temp folder inside of this to take care of that.

So far so good.

Now, I need to change the INI for the server to point to these places. The
settings in the INI are not a problem.   Those can be changed to "uncle
Bill's" scheme with what I set up and all is "almost" well with the world.

Here's the problem.

The Server needs the ini in its folder to... well... get its settings.

But if you stop the server, you can edit these settings and....  wooops.
The INI is in a read only folder.

Soooooooo.

Here's a suggestion that may sound dumb, but its the only thing I can think
of.

Use an INI file in with the app that POINTS to the ini will all the server
settings.   This way the ServerSettings.INI file can be in the R/W place and
the Pointer INI file would typically never get changed.  During install, if
we are choosing a PER user, then we would set the pointer INI to the XXX
user's Application Data\.xxxx folder.   If we want Machine, then we put in
All Users.

Anyways.. Food for thought.

Lance


Sat, Apr 21 2007 9:09 PMPermanent Link

Dave Harrison
Lance R wrote:

> Tim,
>
> There's a sort of chicken / egg thing with permissions that would be nice to
> address.
>
> Please read in the irony and distain in my "voice", but its something to
> consider.
>
> "Uncle Bill" says apps should go into Program Files.  And...  By the way...
> Anything in Program Files is Read Only......  Not a problem.  I'll put the
> ElevateDB server in program files because its just an app.
>
> "Uncle Bill" says data should go into the User's sub folders (or Documents
> and Settings\ for XP).  This is read/write.   Not a problem.  I'll put the
> ElevateDB data in C:\Documents and Settings\All Users\Application
> Data\ElevateDBData so that server only deals with ONE set of data and can
> serve no matter which user logs in.    And since I still need to deal with a
> temp folder, I'll nest the temp folder inside of this to take care of that.
>
> So far so good.
>
> Now, I need to change the INI for the server to point to these places. The
> settings in the INI are not a problem.   Those can be changed to "uncle
> Bill's" scheme with what I set up and all is "almost" well with the world.
>
> Here's the problem.
>
> The Server needs the ini in its folder to... well... get its settings.
>
> But if you stop the server, you can edit these settings and....  wooops.
> The INI is in a read only folder.
>
> Soooooooo.
>
> Here's a suggestion that may sound dumb, but its the only thing I can think
> of.
>
> Use an INI file in with the app that POINTS to the ini will all the server
> settings.   This way the ServerSettings.INI file can be in the R/W place and
> the Pointer INI file would typically never get changed.  During install, if
> we are choosing a PER user, then we would set the pointer INI to the XXX
> user's Application Data\.xxxx folder.   If we want Machine, then we put in
> All Users.
>
> Anyways.. Food for thought.
>
> Lance
>

Lance,
     So how do you change the path in the INI file (which is read only)
that points to the other ini file? Seems like a PIA to me. Why not just
set a registry entry that points to the main .ini file?

Dave
Sat, Apr 21 2007 9:39 PMPermanent Link

Lance Rasmussen

Jazzie Software

Avatar

Team Elevate Team Elevate

An installer could create the pointer INI file on the fly.  Appropriate
permissions
would be needed to install the program anyways.

Registry would be fine too...  You just have to be careful with that.  Vista
can sometimes virtualize a registry entry.

Writing the registry to HKCU isn't a problem.  In theory, it should be fine
if you set HKLM if you are running the server for EVERYONE providing
the installer's privileges elevates to admin.

Lance


> Lance,
>      So how do you change the path in the INI file (which is read only)
> that points to the other ini file? Seems like a PIA to me. Why not just
> set a registry entry that points to the main .ini file?
>
> Dave
Sat, Apr 21 2007 10:58 PMPermanent Link

"Royke"
But wouldn't it be a bit inconsistent to put the data in 'All users' and
then the ini-file location in HKCU?

RJ

"Lance Rasmussen" <lance at lance.ws> wrote in message
news:911BCB83-E05A-4F7A-962F-C8D8A976A1DC@news.elevatesoft.com...
> An installer could create the pointer INI file on the fly.  Appropriate
> permissions
> would be needed to install the program anyways.
>
> Registry would be fine too...  You just have to be careful with that.
> Vista
> can sometimes virtualize a registry entry.
>
> Writing the registry to HKCU isn't a problem.  In theory, it should be
> fine
> if you set HKLM if you are running the server for EVERYONE providing
> the installer's privileges elevates to admin.
>
> Lance
>
>
>> Lance,
>>      So how do you change the path in the INI file (which is read only)
>> that points to the other ini file? Seems like a PIA to me. Why not just
>> set a registry entry that points to the main .ini file?
>>
>> Dave
>

Mon, Apr 23 2007 1:11 PMPermanent Link

"Lance R"
RJ,

yep..  It may have got lost in translation, but you would be correct.

If installing the server at the machine level, you would put the data in
"All Users" and the INI in HKLM.
If installing the server at the user level, you would put the data in
"USERXXX" and the INI in HKCU.

Lance

"Royke" <royke@canada.com> wrote in message
news:0BFFE92E-1D26-41A8-98FC-5AAC66B46096@news.elevatesoft.com...
> But wouldn't it be a bit inconsistent to put the data in 'All users' and
> then the ini-file location in HKCU?
>
> RJ

Mon, Apr 23 2007 4:14 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Lance,

<< Here's a suggestion that may sound dumb, but its the only thing I can
think of. >>

I think I might rather go with a setup that simply stores the server's .INI
in the common application data folder for all users.   I'll have to think
about this some more, but that's my initial thoughts.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Apr 24 2007 12:04 PMPermanent Link

Lance Rasmussen

Jazzie Software

Avatar

Team Elevate Team Elevate

I tend to agree Tim,

The only thought would be if you want the flexibility of installing
different instances of the server for different user accounts.   Personally,
I don't see the need to install the server for anything other than ALL
Users, but thats my humble opinion.

The main thing I wanted to point out was the permissionary issues that are
there with a locked down XP / 2K system, but especially our "favorite" new
MS OS.

Lance


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:2B6E5DCC-1389-41E6-B3CD-391EC2C55C9C@news.elevatesoft.com...
> Lance,
>
> << Here's a suggestion that may sound dumb, but its the only thing I can
> think of. >>
>
> I think I might rather go with a setup that simply stores the server's
> .INI in the common application data folder for all users.   I'll have to
> think about this some more, but that's my initial thoughts.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Wed, Apr 25 2007 8:19 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Lance,

<< The only thought would be if you want the flexibility of installing
different instances of the server for different user accounts.   Personally,
I don't see the need to install the server for anything other than ALL
Users, but thats my humble opinion. >>

Yes, and there's the issue of running it as an application, and then trying
to run it as a service, or vice-versa.  Obviously, it would be best if the
configuration was in a common folder for all users.

<< The main thing I wanted to point out was the permissionary issues that
are there with a locked down XP / 2K system, but especially our "favorite"
new MS OS. >>

Yes, and I appreciate it very much.  I fixed the EDB Manager, but the server
was a bit of an oversight.

--
Tim Young
Elevate Software
www.elevatesoft.com


Image