Valid locations saving pref files

Deploying to Windows? Utilizing VB Script execution? This is the place to ask Windows-specific questions.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
jmk_phd
Posts: 213
Joined: Sat Apr 15, 2017 8:29 pm

Valid locations saving pref files

Post by jmk_phd » Fri Oct 12, 2018 4:32 am

It's my understanding that recent versions of macOS do not permit writing files to the Applications folder, so (a) I create a subfolder in the Documents folder to store generated documents as PDF files, and (b) write a blowfish-encrypted text file to the user's Preferences folder -- specialFoldersPath("preferences") -- the first time a registered user enters the provided license key. Thereafter, upon startup, the app checks for that key file in order to determine whether to display the test in full or demo mode.

Both (a) and (b) work great in macOS. However, whereas writing to the Documents subdirectory (a) works great on an old Windows Vista laptop, it appears that the prefs file (b) was never written to disk, or at least where it might be expected to have been found again upon the next launch of the app. (I confess being largely ignorant of Windows and remiss in not including a line of code to confirm that the prefs file actually had been written to disk.)

BTW, I used the code snippet (function fPrefsfolder) that Klaus has so kindly posted more than a few times to these forums.

Two simple questions:

(1) Can I write my encrypted text file instead to the subdirectory of the Windows Applications folder that contains my standalone -- which is easy enough to identify in LiveCode -- or is writing to this folder prohibited? Having been encrypted, I really don't care whether this file is visible to users. (Because this stamps printed reports with the original registrant's name, professional clinicians who employ a pirated license should be shamed by having someone else's name appear on their reports.)

(2) Assuming that this is not prohibited for now, how can I know when Windows eventually emulates Apple's draconian security restrictions and limits where preferences files can be written?

Thanks!

jeff k

SparkOut
Posts: 2839
Joined: Sun Sep 23, 2007 4:58 pm

Re: Valid locations saving pref files

Post by SparkOut » Fri Oct 12, 2018 6:55 am

I think Windows started restricting general write access to "Program Files" a long time ago on Windows XP or maybe even earlier.

Ken Ray made a definitve list of file locations http://www.sonsothunder.com/devres/live ... ile010.htm
This is "old" but still valid and even on Windows 10 the CSIDL code should map to the correct place. You will probably find the ProgramData folder most appropriate and could try specialFolderPath (35)

jmk_phd
Posts: 213
Joined: Sat Apr 15, 2017 8:29 pm

Re: Valid locations saving pref files

Post by jmk_phd » Mon Oct 15, 2018 1:40 am

Hi, SparkOut --

Thanks much for confirming that Windows already restricts write access to the "Program Files" directory.

I had in fact already employed your recommended specialFolderPath(35) in my original code in the case that the platform function returned "Win32". This failed.

However, when I rewrote this to employ specialFolderPath(26) -- which is presumably accessible only to the current user -- the encrypted text file containing the entered registration info apparently was written to disk. When I quit and relaunched the app, it did indeed find and read that file, thereby unlocking the full app. Success!

I've been testing my Windows standalone on a borrowed PC laptop running Windows Vista. As a Mac-only user, I've never used Windows before, so I have no skill in navigating that interface. One possibility -- just speculation -- is that the owner of this laptop employed security settings that prevented me from writing to the shared ProgramData folder.

If that's the case, my solution may be overly restrictive.

Still, I'm hoping that the strategy of writing to a current-user-only folder will adversely affect very few if any Windows users.

Thanks again for your help.

jeff k

SparkOut
Posts: 2839
Joined: Sun Sep 23, 2007 4:58 pm

Re: Valid locations saving pref files

Post by SparkOut » Mon Oct 15, 2018 7:54 am

That's odd, I use specialFolderPath(35) without problem for files common to the install (rather than the user). I don't think it should be a user-set security problem, possibly the user account you have signed in as only has guest access rights, but I'd have thought you would have noticed other restrictions already.

Can you manually create a folder or file in C:\ProgramData? And if you then try to put "something" into url("file:" & specialFolderPath (35) & "/test.txt") and answer the result, what do you get?

jmk_phd
Posts: 213
Joined: Sat Apr 15, 2017 8:29 pm

Re: Valid locations saving pref files

Post by jmk_phd » Mon Oct 15, 2018 8:57 am

You wrote:
I don't think it should be a user-set security problem, possibly the user account you have signed in as only has guest access rights, but I'd have thought you would have noticed other restrictions already.
You give me too much credit. Although I've been programming for the Mac since the introduction of HyperCard 2.0 -- hence my love of LiveCode -- I'm embarrassed to report that it's a stretch for me even to figure out how to run my app on a PC. (This Windows Vista laptop was borrowed from a fellow clueless Mac user, who in turn had borrowed it from a marginally competent Windows user, so any access rights set for this machine are a mystery.)

I will create a standalone that employs specialFolderPath(35), but -- inasmuch as all of my family/friends are Mac users -- I'll just have to find a Windows-savvy user to give it a try.

Thanks again for your help.

jeff k

AxWald
Posts: 578
Joined: Thu Mar 06, 2014 2:57 pm

Re: Valid locations saving pref files

Post by AxWald » Mon Oct 15, 2018 9:54 am

Hi,

"ProgramData" is one of the "mapped folders" in newer Windows systems. They can be tricky to work with. Using another approach I accidentally came to a way to write there:

Code: Select all

   set itemdel to slash
   put specialFolderPath(40) into myPath  --  the User Folder
   put last item of myPath into myName  --  save for later
   delete last item of myPath
   put slash & "All Users" after myPath
   create folder myPath & slash & "myApp"  --  C:/Users/All Users/myApp
   
   --  check for errors:
   get the result 
   if it is not empty then
      if there is a folder (myPath & slash & "myApp") then
         answer "Prefs folder already exists!"
         --  check if you already have a prefs file?
         exit mouseUp
      else
         answer "Cannot create prefs folder!" & CR & it
         --  something went wrong :/
         exit mouseUp
      end if
   end if
   
   --  create the file with dummy content:
   put "someText" into URL ("file:" & (myPath & slash & "myApp" & slash & "myPref.pref"))
   put "Create file, content: " & the result & URL ("file:" & (myPath & slash & "myApp" & slash & "myPref.pref")) & CR after myRes
   
   --  replace content with your user name:
   put myName into URL ("file:" & (myPath & slash & "myApp" & slash & "myPref.pref"))
   put "Modify file, content: " & the result & URL ("file:" & (myPath & slash & "myApp" & slash & "myPref.pref")) & CR after myRes
   put myRes
Now you have a folder "myApp" with your "myPref.pref" in "Users\All Users". You have created the folder, the file, and modified the file.
And if you doublecheck, all this is actually in "ProgramData", too ;-))

Tested on Win 10-64 with strict UAC settings. Have fun!
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!

jmk_phd
Posts: 213
Joined: Sat Apr 15, 2017 8:29 pm

Re: Valid locations saving pref files

Post by jmk_phd » Tue Oct 16, 2018 2:08 am

Hi AxWald --

Thanks much for your feedback. If the problem using specialFolderPath(35) persists, I definitely will give your approach a try.

Your code snippet is yet another important reminder to include scrupulous error-checking in my code. All too easy simply to assume that a routine will work as expected just because it seems sensible, then be at a loss when it doesn't.

Best,

jeff k

Post Reply

Return to “Windows”