Problem with Vista: "Run-Time error '75': Path/File access error"
in [Visual Basic]
|
Prev: Sorting UDTs
Next: Copy from ListBox to TextBox
From: Viken Cerpovna on 28 Jun 2010 19:54 >> http://msdn.microsoft.com/en-us/library/ms995853.aspx#w2kcli_req42 > > So the way I read that is, feel free to modify your own subdirectory > security settings, but DO NOT modify the APPDATA directory in any such > way. > > -- > .NET: It's About Trust! > http://vfred.mvps.org Which begs the question, has it been changed at some point to impact access to the files, or does the file itself have permissions set (not inherited from the parent) so that it cannot be accessed or updated? Viken
From: Karl E. Peterson on 28 Jun 2010 20:00 Viken Cerpovna was thinking very hard : >>> http://msdn.microsoft.com/en-us/library/ms995853.aspx#w2kcli_req42 >> >> So the way I read that is, feel free to modify your own subdirectory >> security settings, but DO NOT modify the APPDATA directory in any such way. > > Which begs the question, has it been changed at some point to impact access > to the files, or does the file itself have permissions set (not inherited > from the parent) so that it cannot be accessed or updated? Lacking details, my bet would be that a setup program put the files there in the first place, which is perfectly legit. (Just as they can write to HKLM.) So nothing really changed, other than the permissions the accessing processes were operating under. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Tony Toews on 28 Jun 2010 21:33 On Mon, 28 Jun 2010 18:39:33 -0400, "Claire" <replyto(a)fra> wrote: >When installing app to be used by all users how should the program be >installed? The program should still be installed by an admin account to Program Files. (However I've noticed that, among other things. Google Update and Chrome are now putting exes in APPDATA which are user updatable. Hmm, interesting. It appears MapPoint 2006 put some assembly DLLs in there too.) (I use Chrome stictlly for Facebook and nothing else so FB can't pass my information to other websites. ) >I understand that HKLM must be used regarding the registry but how about app >path? HKCU can also be used for user settings. Athough I prefer INI files. >My app creates logs, keeps preferences in ini file, Those should go into the indvidual user APPDATA folder. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews on 28 Jun 2010 21:37 On Mon, 28 Jun 2010 16:21:19 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: >>> I would suspect a permissions problem. Have you tried checking the >>> Privilege Level option for the application shortcut (Compatibility tab) to >>> "Run this program as an administrator"? >>> >>> If this fixes the problem then you probably need to tweak the security >>> settings on the APPDATA folder. >> >> # CSIDL_COMMON_APPDATA >> >> This folder should be used for application data that is not user specific. >> For example, an application may store a spell check dictionary, a database of >> clip-art or a log file in the CSIDL_COMMON_APPDATA folder. This information >> will not roam and is available to anyone using the computer. By default, this >> location is read-only for normal (non-admin, non-power) Users. If an >> application requires normal Users to have write access to an application >> specific subdirectory of CSIDL_COMMON_APPDATA, then the application must >> explicitly modify the security on that sub-directory during application >> setup. The modified security must be documented in the Vendor Questionnaire. >> >> http://msdn.microsoft.com/en-us/library/ms995853.aspx#w2kcli_req42 > >So the way I read that is, feel free to modify your own subdirectory >security settings, but DO NOT modify the APPDATA directory in any such >way. No, that's now quite how I read that. That paragraph you quote is about Common_Appdata which, IIRC, is updatable only by admins. Your sentence is about APPDATA.. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews on 28 Jun 2010 21:40
On Mon, 28 Jun 2010 18:54:36 -0500, "Viken Cerpovna" <viken(a)spam.com> wrote: >Which begs the question, has it been changed at some point to impact access >to the files, or does the file itself have permissions set (not inherited >from the parent) so that it cannot be accessed or updated? Windows Vista and newer locked down the Common_Appdata folder. I started receiving complaints about my Auto FE Updater not being able to create shortcuts on the common desktop in Windows Vista so I deprecated that feature in myutility. Thus I suggest the users desktop., among other places. (I had one person recently email stating theiir IT depertment had even locked down the desktop to being unable to create shortcuts. So I added the ability to create shortcuts in the My Documents folder.) Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/ |