locked
Properties.Settings and redirected appdata folders RRS feed

  • Question

  • Hi,
    I have an issue with a customer configuration and the saving of app settings (roaming).
    The customer redirects the user appdata folder to a file server. The user has full control at this directory.
    When our application starts, the user.config is created in the right directory.
    But when we try to save setting changes, a System.UnauthorizedAccessException occurs.
    This is because .NET tries to set ACLs.
    From callstack:
    StackTrace =>

       at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)
       at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext)
       at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections, Object exceptionContext)
       at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections)
       at System.Security.AccessControl.FileSystemSecurity.Persist(String fullPath)
       at System.IO.File.SetAccessControl(String path, FileSecurity fileSecurity)
       at System.Configuration.Internal.WriteFileContext.DuplicateTemplateAttributes(String source, String destination)
       at System.Configuration.Internal.WriteFileContext.DuplicateFileAttributes(String source, String destination)
       at System.Configuration.Internal.WriteFileContext.Complete(String filename, Boolean success)
       at System.Configuration.Internal.InternalConfigHost.StaticWriteCompleted(String streamName, Boolean success, Object writeContext, Boolean assertPermissions)
       at System.Configuration.Internal.InternalConfigHost.System.Configuration.Internal.IInternalConfigHost.WriteCompleted(String streamName, Boolean success, Object writeContext, Boolean assertPermissions)
       at System.Configuration.Internal.DelegatingConfigHost.WriteCompleted(String streamName, Boolean success, Object writeContext, Boolean assertPermissions)
       at System.Configuration.ClientSettingsStore.ClientSettingsConfigurationHost.WriteCompleted(String streamName, Boolean success, Object writeContext)
       at System.Configuration.UpdateConfigHost.WriteCompleted(String streamName, Boolean success, Object writeContext)
       at System.Configuration.MgmtConfigurationRecord.SaveAs(String filename, ConfigurationSaveMode saveMode, Boolean forceUpdateAll)
       at System.Configuration.Configuration.SaveAsImpl(String filename, ConfigurationSaveMode saveMode, Boolean forceSaveAll)
       at System.Configuration.ClientSettingsStore.WriteSettings(String sectionName, Boolean isRoaming, IDictionary newSettings)
       at System.Configuration.LocalFileSettingsProvider.SetPropertyValues(SettingsContext context, SettingsPropertyValueCollection values)
       at System.Configuration.SettingsBase.SaveCore()
       at System.Configuration.SettingsBase.Save()
       at System.Configuration.ApplicationSettingsBase.Save()
       at Properties.Settings.Default.Save()

    Why does .NET try to set ACLs here? Is there a way to avoid this?

    What is the recommended way to handle redirected appdata directories?

    Kind Regards
    Thursday, June 27, 2019 10:39 AM

All replies

  • Hi silke.p,

    Thank you for posting here.

    For your question, how does the .NET set ACLs in your code? Could you provide more details about this? According to your description, I could not make sure what used to set the ACLs.

    Best Regards,

    Wendy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, July 1, 2019 2:35 AM
  • Hi Wendy, 

    please take a look at the callstack above. 

    I call the method Save() from my code with: 
    Properties.Settings.Default.Save()

    The user.config exists already and has to be updated. 

    Then everything after the call of Properties.Settings.Default.Save() is running within the .net Framework. 
    The method that tries to set the ACLs is this one I suppose: 
    System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl)

    I wonder why this is necessary and how I can avoid it? 

    Kind Regards

    Monday, July 1, 2019 9:14 AM
  • Hi silke.p,

    For this error message, do you try to set the higher permission like run as admin?

    And when you save the settings, please check the file exist or not first.

    Best Regards,

    Wendy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, July 2, 2019 9:08 AM
  • Hi Wendy, 

    no I don't try to set higher permission. 

    I can check if the file exists or not, but what's the difference? What action should I execute if file exists or not?


    Kind Regards

    Tuesday, July 2, 2019 2:12 PM
  • Hi silke.p,

    For the error message, we normally try the two ways I mentioned at my previous reply to fix this issue.

    Please have a try. 

    And before save the settings, use something like if statement to judge the file exists or not.

    Best Regards,

    Wendy


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, July 3, 2019 2:19 AM