What to do when Specialfolder.ApplicationData is read only ?

After trying unsuccessfully to work around strange crashes of Check Writer III+ on Windows 10, I discovered that some IT managers prevent access to %AppData% altogether (Specialfolder.ApplicationData is the \Roaming folder inside %AppData%).

So, since my app upon first launch tries to create a subfolder in Specialfolder.ApplicationData and cannot, it simply crashes badly.

The next version will verify if the directory is writable, and display a MsgBox explaining the app cannot run unless the IT manager relinquishes access. But it is not ideal.

I have been toying with the idea to create a subfolder next to the executable, or in the user Documents folder, as bad as it looks, but after all, if that spares the embarrassment…

Any body ran into the same situation ? Any ideas ?

I have come to the belief that the primary function of any IT manager appears to be to prevent anyone doing their work, in order that they do nothing to cause an IT manager to have to do some.

Obviously if the data you expected to put there is not going to be written to, it can be installed as a resource for your app into the MyApp Resources folder with the app.

If you need to write to it and ApplicationData is missing or read-only, (I get the same issue now and then with Specialfolder.documents) then all you can do is stop and ask them to browse to a place where they ARE allowed to write files, and record what they give you in a registry setting for next time.
Assuming you are allowed to do THAT… :wink:

I wouldn’t be superstitious about trying the user’s documents folder. Many people - those who take data backups anyway - just back up that folder.

My issue with the documents folder is that some stupid individuals may mess up with the data, and then blame the app for their own incompetence.

Jeff’s idea is worth exploring. After all, resources is a nice place to put critical files. I am going to experiment.

Thank you.

Why show a MsxBox trying to explain about AppData/Roaming - most users won’t have a clue what you’re talking about.
One idea: If Specialfolder.ApplicationData is not writable, then ask the user where he/she wants to save your App’s data (ask to create a folder). Maybe that doesn’t look as “bad” (as to create a subfolder in Documents without asking)?

Just don’t bump into “You can’t do that here” rights issues.

I’ve been doing that instead of ApplicationData for 8 years
It allows me to let the users get at the ‘editable resources’ much more easily than explaining how to access a hidden-by-default special location.
Not one complaint, and only 3 IT Manager style issues in that time.

[quote=373170:@Jeff Tullin]I’ve been doing that instead of ApplicationData for 8 years
It allows me to let the users get at the ‘editable resources’ much more easily[/quote]
Doing the same here.

I also gave the user path (buttons in a special window) / a way to go directly where (s)he want by a click that shows that application file / folder. After several phone calls to know “how do I access” this or that object. No more phone call for that.

You may find that this is the way they prevent users from installing apps without IT consent. It could be as simple as you are not allowed to create the directory when running as a regular user.

Have you tried requiring administrator rights to run your installer?

I can’t imagine putting application configuration data anywhere except in AppData. We’ve been doing this for years and if we do run into a problem with the user not being able to access that location, it happens when they try to install our software. We simple explain that they must have rights to the folder we try to create in AppData or they won’t be able to run and update our software.

Once this is explained to their IT staff (that’s the only time we’ve run into this issue… when they have an IT staff), they make the necessary changes.

OK. I am going to simply create my save folder in Resources, as suggested by Jeff Tulin. Then I look if a folder already exists in specialFolder.ApplicationData, and if so, I copy everything to my Resources subfolder (for people who already have the app) and got updated.

That should be transparent to the user, and to hell with stupid IT managers.

If your app is in Program Files or Applications (Mac) the OS won’t want you to WRITE there… Resources is only really good for read-only stuff.

I imagine you could do it with elevated permissions, but thats also unlikely if they IT people are strict

We use a folder in the SpecialFolder.SharedApplicationData where we store specific information about the user of our software. This is typically the PROGRAM DATA folder in Windows and it is normally hidden but you can still see it and write to it. Not sure about the rights required to write to it though, but it is not user specific like the AppData folder is.

This is a Windows thread. On Mac, I never, ever, had a user encounter a stupid non writable SpecialFolder.ApplicationData, so it will stay there.

At any rate, there are so much discrepancies between platforms, I have separated the two sources.

[quote=373195:@Michel Bujardet]OK. I am going to simply create my save folder in Resources, as suggested by Jeff Tulin. Then I look if a folder already exists in specialFolder.ApplicationData, and if so, I copy everything to my Resources subfolder (for people who already have the app) and got updated.

That should be transparent to the user, and to hell with stupid IT managers.[/quote]
I wouldn’t recommend this. While most users run inside an administrator account (not advised) you shouldn’t count on this. If your app is installed in Program Files, as it most likely is, then the resources will be read-only to standard users. Just like on macOS, this folder is NOT supposed to be written to, it’s just not as strictly enforced because Microsoft puts such a high value on backwards compatibility.

AppData is unequivocally the correct location, so you should keep it there for most users and only fall back to another location if there is trouble. I agree that Documents is probably the best backup location. I would do it something like

[code]Public Function ApplicationSupport() as FolderItem
Static SupportFolder As FolderItem
If SupportFolder <> Nil And SupportFolder.Exists Then
Return SupportFolder
End If

Dim BackupFolder As FolderItem = SpecialFolder.Documents.Child(“MyApp Data”)
If BackupFolder <> Nil And BackupFolder.Exists Then
SupportFolder = BackupFolder
Return SupportFolder
End If

Dim AppDataFolder As FolderItem = SpecialFolder.Documents.Child(“MyApp”)
If AppDataFolder <> Then
If AppDataFolder.Exists Then
SupportFolder = AppDataFolder
Return SupportFolder
End If

AppDataFolder.CreateAsFolder
If AppDataFolder.LastErrorCode = 0 Then
  SupportFolder = AppDataFolder
  Return SupportFolder
End If

End If

If BackupFolder <> Nil Then
BackupFolder.CreateAsFolder
If BackupFolder.LastErrorCode = 0 Then
SupportFolder = BackupFolder
Return SupportFolder
End If
End If

// … Honestly not sure what to do now. Return something in temporary?
SupportFolder = SpecialFolder.Temporary.Child(“MyApp Transient”)
Return SupportFolder
End Function[/code]

Though as you see at the end, I have no idea what the best option would be if even your backup location fails.

I wouldn’t do that. Some companies move their user’s Document folder from the default location on the C: Drive to another location on a network drive so that they can backup and scan the user’s documents more easily. The problem is when the user disconnects from the network they may not have access to your data files that you put there. Used to run into that several times a year until we started putting the data in ApplicationData.

Hm, so it seems that this might be the best solution?

if SpecialFolder.ApplicationData.IsWritable = false then MsgBox("IT Error" + EndOfLine + EndOfLine + "It looks like your IT department has gotten a little wild and locked the %AppData% folder. To run this application you'll need to get permission from your IT department.") end

Until what point the developer can try to (have to) avoid what IT, User or other people can do (moving folders, changing permissions, etc.) ?

A good question is… where these IT Managers want the running application(s) read/write the application data ?
Are their user know where their data have to be read / write ? (Documents)

Also:
How do (major) software provider (FireFox comes to mind) deal with that (eventual) problem ?
The user can choose its own Download folder, but where Firefox store its “internal” data ? Can you ask your users with troubles to report where these folders are stored on their Windows machines ?

[quote=373273:@Tim Parnell]Hm, so it seems that this might be the best solution?

if SpecialFolder.ApplicationData.IsWritable = false then MsgBox("IT Error" + EndOfLine + EndOfLine + "It looks like your IT department has gotten a little wild and locked the %AppData% folder. To run this application you'll need to get permission from your IT department.") end [/quote]

That is exactly what I did, until this discussion took me in all sorts of alternative solutions.

The worst being that I also have a Windows Store version, where using Resources is completely out of question, since the app is wrapped in an AppX.

Final decision :

  • If SpecialFolder.ApplicationData iswriteable, I save there
  • If not SpecialFolder.ApplicationData iswriteable and it is not a Windows Store app, I save in Resources (if writeable)
  • If none of these options work, I display a messageDialog offering to quit, or print the message for the IT manager :

This machine is set to prevent writing to the %AppData% folder. Our app needs access to that folder to save data. Please contact your IT manager to fix this issue. This app cannot continue, and will now quit.

I dismissed the choice of a random folder by the user saved in the registry, because the registry itself can be made off limit. I verified that Microsoft indeed recommends the use of %AppData% to save apps settings. At one point, when the IT manager makes things impossible, an app developer should not be blamed for the stupidity of the person in charge of hardware.