Problem with Vista: "Run-Time error '75': Path/File access error"
in [Visual Basic]
|
Prev: Sorting UDTs
Next: Copy from ListBox to TextBox
From: Tony Toews on 28 Jun 2010 23:35 On Mon, 28 Jun 2010 23:18:41 -0400, "Kevin Provance" <k(a)p.c> wrote: >: 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 see this too sometimes. And until I read a reliable article from MSFT >explaining why or encouraging that kind of behaviour, it's a sign of either >malware or sloppy programming...or both. <g> > >IOW...DON'T DO IT MAN!!!! I'm not and I have no intentions of it. Yet. That said I'm recommending Access FE (rront ends containing queires, forms, reports and modules) files be placed into APPDATA as they are somewhat updated by Access with small amounts of data such as Query Plans and such. Also this way new Access FE files can be updated from the server without getting the IT dept involved. Also, as you are likely aware due to my frequent questions to this newsgroup, my Auto FE updater utiliity is a drag and drop deployment to the server. Which would no doubt horrify the IT dept if they knew about it. <smile> (Which is one reason I digitally sign the exe.) A future release will give the user the capability of copying down my VB6 exe to the local system mostly for the situation where the user is storing data in a replicated database on their laptop. And they want to take that laptop with them to clients sites. And when this functionality is added then yes I'll be putting the VB6 exe in the APPDATA folder. If a new version is available on the server then I'll be copying down the new version to 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: Mayayana on 29 Jun 2010 09:48 | : 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 see this too sometimes. And until I read a reliable article from MSFT | explaining why or encouraging that kind of behaviour, it's a sign of either | malware or sloppy programming...or both. <g> | An increasing number of programs are installing with "transparent" self-updating. To my mind that's malware (and I consider Chrome to be malware), but the auto-update trend is not likely to go away, despite people repeatedly losing their installs due to bad updates (like the recent McAffee problem). If you've got numerous programs that self-update (which MS supports) and you want to run in lackey mode with UAC enabled (which MS recommends) and you install to Program Files (which MS recommends), and you leave restricted access settings on the program folder (which MS recommends), then one doesn't need to wait for official Microsoft articles to figure out that something is missing in that logic. :)
From: RDub on 29 Jun 2010 11:14 Wow talk about a timely post. I am just getting ready to go Beta on an app that up until yesterday was using CSIDL_COMMON_APPDATA to store temp and backup data. The thing is in all my testing both as a standard user and a Admin in XP, Vista, and Win 7 this was working with no problems. My App (not the install app) was able to create a directory 2 levels down (CompanyName/AppName) from CSIDL_COMMON_APPDATA and read write to my hearts content. I am curious if anyone can explain why my app has not thrown an error when being run from a Standard User account in Vista or Win 7. However after reading all the way through this thread, I have decided not to temp fate, and to go with CSIDL_LOCAL_APPDATA which if I understand correctly should never present a problem for any user attempting read/write. Thanks again to all Rdub "Claire" <replyto(a)fra> wrote in message news:%23YNF4cuFLHA.1272(a)TK2MSFTNGP05.phx.gbl... > Hello, > I am not sure what I am doing wrong. > The fact is that I cannot recreate the problem on my computer, one of my > users is struggling with. > The problem is that on his computer app crashes with: > "Run-Time error '75': Path/File access error" message. > I have traced this problem to the point app wants to create folder in: > C:\ProgramData\<my app title> > That path is obtained using GetSpecialfolder(CSIDL_COMMON_APPDATA) > > Interestingly, I cannot recreate that crash on my computer. > > User has Vista Business (32 bit), with Administrator privilages and UAC is > on. > > I have also noticed another strange thing about that Vista. > It returns False to IsWinNT4Plus function: > ============================ > Function IsWinNT4Plus() As Boolean > Const VER_PLATFORM_WIN32_NT As Long = 2 > Dim osv As OSVERSIONINFO > > osv.OSVSize = Len(osv) > If GetVersionEx(osv) = 1 Then > IsWinNT4Plus = (osv.PlatformID = VER_PLATFORM_WIN32_NT) And > (osv.dwVerMajor >= 4) > End If > End Function > ============================ > > Any comments and your help appreciated, > Claire > >
From: Karl E. Peterson on 29 Jun 2010 12:11 Tony Toews formulated on Monday : > 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.. Inadvertant truncation. I meant what I meant, not what I said. <g> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 29 Jun 2010 12:13
Tony Toews has brought this to us : > On Mon, 28 Jun 2010 16:20:22 -0700, Karl E. Peterson <karl(a)exmvps.org> > wrote: > >> # CSIDL_COMMON_APPDATA > > Speaking of APPDATA almost data in the APPDATA is settings or > "temporary" files which can be ignored if a hard drive starts to fail. > After all most applications store genuine user data, such as photos, > documents, Excel files, ec in My Documents. > > And people know to do a backup of My Documents. Ok, only once a year > maybe if that but people know about it. > > WIth two exceptiosn. Outlook and Outlook Express. For some unknown > reason MS puts those in APPDATA. OE put it's data files stuff way > inside in a GUID folder even as I found out last Thursday. <sigh> Both are inexcusable, of course. I do think even Microsoft understands Outlook data has some value. But they've always considered OE data to be disposable, as demonstrated by them *deleteing* it immediately when OE finds it's no longer on the server! -- ..NET: It's About Trust! http://vfred.mvps.org |