Prev: ptr belongs to dynamic memory ???
Next: Errors with dbFileSpec Create
From: dlzc on 28 Jul 2010 14:59
Dear Massimo Bighelli:

On Jul 28, 11:01 am, "Massimo Bighelli" <i...(a)arcasistemi.it> wrote:
....
> I don't have my w7ult64 in hand now, but curious
> tried on VistaB64 creating a new dir under C,
> ie c:\agenda, and copying all files in c:\agenda,
> all seems working correctly. I don't see any
> problem running my app "agenda" in that dir, nor
> accessing the c:\agenda path.
> Is there something different in w7 ?

Yes.
http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/8b587826-b3f6-4db2-8b4e-c4e08baa7b62

Micro$haft has been warning us it was coming. They consider it a
security risk to let applications "scatter" across the hard drive, and
settings for the user might not be captured on a backup, if "we" don't
follow "The Plan".

David A. Smith
From: Massimo Bighelli on 28 Jul 2010 16:00
David,

THX a lot.

Interesting, and something new to learn
This is from Microsoft Online Community Support:

>>
Please run "gpedit.msc" to open GPO editor, navigate to "Computer
Configuration" - "Windows Setting" - "Security Settings" - "Local
Policies" - "Security Options", disable the relevant UAC settings, then
restart the settings, try to create files on C driver.
--------------------
Regards,
Eric Zhang
Microsoft Online Community Support
<<

>>
That is by design and is a function of User Account Control (UAC) and the
ACL on the root of the drive. The ACL permits only Administrators and System
from writing files to the root of the drive. UAC means that even if you are
a
member of the Administrator's group you do not run as an administrator
unless
you elevate.

If you really want to, you can launch whatever process you use to write the
files with as an administrator and then you can write there. If you try to
drag and drop a file there you get an elevation prompt. The recommended
solution is to not store data there though.

or

If you really are adamant about storing files in the root of the C: and you
do not want to
elevate each time, you can resolve the situation by adding an access control
list entry for your account to the root of the drive, as follows:
1. Click the Window button:All Programs:Accessories
2. Right-click on Command Prompt
3. Select Run as administrator and accept the prompt
4. Run this command: icacls c:\ /grant foo (OI)(CI)(M)

That will grant the user foo modify permissions on c:\. All objects (OI) and
containers (CI) will inherit those permissions. You would need to replace
foo
with the name of your user account.

Once you do that any application you run as user foo will be able to store
data in the root of the C: drive. You will also have losened a default
security setting, with all the caveats that entails.
<<




"dlzc" <dlzc1(a)cox.net> ha scritto nel messaggio
news:fdd93d89-f876-4213-acd0-11d811615ff7(a)i19g2000pro.googlegroups.com...
Dear Massimo Bighelli:

On Jul 28, 11:01 am, "Massimo Bighelli" <i...(a)arcasistemi.it> wrote:
....
> I don't have my w7ult64 in hand now, but curious
> tried on VistaB64 creating a new dir under C,
> ie c:\agenda, and copying all files in c:\agenda,
> all seems working correctly. I don't see any
> problem running my app "agenda" in that dir, nor
> accessing the c:\agenda path.
> Is there something different in w7 ?

Yes.
http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/8b587826-b3f6-4db2-8b4e-c4e08baa7b62

Micro$haft has been warning us it was coming. They consider it a
security risk to let applications "scatter" across the hard drive, and
settings for the user might not be captured on a backup, if "we" don't
follow "The Plan".

David A. Smith


--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: dlzc on 28 Jul 2010 16:28
On Jul 28, 1:00 pm, "Massimo Bighelli" <i...(a)arcasistemi.it> wrote:
> David,
>
> THX a lot.
>
> Interesting, and something new to learn
> This is from Microsoft Online Community Support:
....
> Once you do that any application you run as user
> foo will be able to store data in the root of the
> C: drive. You will also have losened a default
> security setting, with all the caveats that entails.

Read that last sentence as "Your customers that have an IT guy that is
not an idiot, will not be able to run your program." Because they
will not allow the UAC to be disabled, nor allow their users to run
with Administrative rights.

Much better to be installed in the User's dedicated account area (or
"All Users"), and/or store all your data / settings there. Better to
ride the horse in the direction it is going...

David A. Smith
From: Massimo Bighelli on 28 Jul 2010 16:38
Oh... yes!

BTW, I agree with the horse direction


Massimo



"dlzc" <dlzc1(a)cox.net> ha scritto nel messaggio
news:68581caf-0e22-4a08-a27e-f3c1ce761742(a)z30g2000prg.googlegroups.com...
On Jul 28, 1:00 pm, "Massimo Bighelli" <i...(a)arcasistemi.it> wrote:
> David,
>
> THX a lot.
>
> Interesting, and something new to learn
> This is from Microsoft Online Community Support:
....
> Once you do that any application you run as user
> foo will be able to store data in the root of the
> C: drive. You will also have losened a default
> security setting, with all the caveats that entails.

Read that last sentence as "Your customers that have an IT guy that is
not an idiot, will not be able to run your program." Because they
will not allow the UAC to be disabled, nor allow their users to run
with Administrative rights.

Much better to be installed in the User's dedicated account area (or
"All Users"), and/or store all your data / settings there. Better to
ride the horse in the direction it is going...

David A. Smith


--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Alessandro Vacchiano on 29 Jul 2010 02:34
Hi Mario,

> On Win7 i cannot work with my app longer than 4 minutes without an 5333er
> or another error like "no exportet method" or i recive a window from win7
> "xxxx does not work anymore and stop caused to a problem..."

I solve this problem simply upgrading VO from 2.6 to 2.7B (VO2.7A version
doesn't work , get same 5333 problem) in W7 64 .

ciao
Alessandro

"Mario Schulz" <info(a)removethiswegenspamconcept-dv.de> ha scritto nel
messaggio news:i2ooo6$b89$1(a)online.de...
> Hi all,
>
> i have a big App with Cavo 2.6.. Since WindowsNT,Win2000, WinXP the app
> works stable exept 1 or 2 5333er per quarter..
>
> On Win7 i cannot work with my app longer than 4 minutes without an 5333er
> or another error like "no exportet method" or i recive a window from win7
> "xxxx does not work anymore and stop caused to a problem..."
>
>
> i try following :
>
> - the Data Execution Prevention turned off
> - under properties the app switch to XP compatibility
> - in the Startup in my App from 80 to DynSize(220)
> - in the Startup der App "\Software\ComputerAssociates\CA-Visual Objects
> Applications\Runtime","MaxDynSpace",67108864)
>
> - in the Startup der App "\Software\ComputerAssociates\CA-Visual Objects
> Applications\Runtime","WipeDynSpace",1)
>
> - all mefs exportet and the AEF´s rebuild during single import the mef´s
> - Reindex, Retouch all the time
>
> nothing solved my problem... i do a little work e.g. append a new article,
> switch to another point of the app and wuummms...
>
> do you have any other ideas what can i do or what going on with win7 ?
>
> bye,
> Mario
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ptr belongs to dynamic memory ???
Next: Errors with dbFileSpec Create