What to do when Specialfolder.ApplicationData is read only ?

  1. 3 months ago

    Michel B

    Feb 12 Pre-Release Testers RubberViews.com
    Edited 3 months ago

    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 ?

  2. Jeff T

    Feb 12 Midlands of England, Europe

    some IT managers prevent access to %AppData% altogether

    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.. ;)

  3. Peter J

    is not verified Feb 12 KwaZulu-Natal, South Africa

    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.

  4. Michel B

    Feb 12 Pre-Release Testers RubberViews.com

    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.

  5. Jürg O

    Feb 12 Pre-Release Testers, Xojo Pro

    @Michel B 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 ideas ?

    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)?

  6. Peter J

    is not verified Feb 12 KwaZulu-Natal, South Africa

    Just don't bump into "You can't do that here" rights issues.

  7. Jeff T

    Feb 12 Midlands of England, Europe

    create a subfolder in Documents without asking)

    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.

  8. Emile S

    Feb 12 Europe (France, Strasbourg)

    @Jeff T 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

    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.

  9. Greg O

    Feb 12 Xojo Inc Somewhere near Raleigh, NC
    Edited 3 months ago

    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?

  10. John F

    Feb 12 Pre-Release Testers, Xojo Pro Omaha, Nebraska

    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.

  11. Michel B

    Feb 12 Pre-Release Testers RubberViews.com
    Edited 3 months ago

    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.

  12. Jeff T

    Feb 12 Midlands of England, Europe

    simply create my save folder in Resources

    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.

    if the data you expected to put there is not going to be written to

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

  13. John F

    Feb 12 Pre-Release Testers, Xojo Pro Omaha, Nebraska

    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.

  14. Michel B

    Feb 12 Pre-Release Testers RubberViews.com
    Edited 3 months ago

    @Jeff T 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.

    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.

  15. Thom M

    Feb 12 Pre-Release Testers Greater Hartford Area, CT

    @Michel B 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.

    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

    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

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

  16. Merv P

    Feb 12 Pre-Release Testers, Xojo Pro

    @Michel B or in the user Documents folder, as bad as it looks,

    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.

  17. Tim P

    Feb 12 Pre-Release Testers, XDC Speakers

    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
  18. Emile S

    Feb 12 Europe (France, Strasbourg)

    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 ?

  19. Michel B

    Feb 13 Pre-Release Testers RubberViews.com
    Edited 3 months ago

    @Tim P 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

    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.

  20. Michel B

    Feb 14 Pre-Release Testers RubberViews.com
    Edited 3 months ago

    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.

or Sign Up to reply!