none
Where to store shared files? RRS feed

  • Question

  • My application may be used by multiple users on the same pc, and will need to have read/write access to some files that will be shared amongst the users. Which folder should I use by default to store such files?

    I am coding in VB.Net and have been using My.Computer.FileSystem.SpecialDirectories.AllUsersApplicationData, but I've discovered that by default standard users in Windows XP don't get write access to files in this folder. I haven't yet tried it with Vista or Windows 7, but would guess it would be the same.

    Is there a better place that exists that I should use, or will I need to create a folder and assign the necessary rights in my setup program?

    TIA
    Phil

    Wednesday, September 15, 2010 12:41 PM

Answers

  • Thanks Derek,

    I will look further into Isolated Storage when I get a bit more time. For now I think I'll stick with putting files into the application common data folder, and make sure I set the necessary permissions in my installer class.

    Cheers,

    Phil.

    • Marked as answer by eryang Wednesday, September 29, 2010 1:32 AM
    Tuesday, September 21, 2010 8:48 AM

All replies

  • You are storing the files at the right directory. However, you should not use the hardcode path you should use Environment.SpecialFolder to get the path of CommonApplicationData folder.

    To get your application going perform follwoing steps

    During instalation of the application (because you will run as administrator during installation).

    1) Create a folder in CommonApplicationData such that CommonApplicationData\<CompanyName>\<ApplicationName>\SharedData

    2) Grant authenticated users Write and Read permissions on SharedData folder.

    3) Use this filder to keep files which are shared.

    Note: Creating folders in above way is not mandatory, its just a cleaner way, so that you can organize all your folders in the commonappdata. You see this problem because all the users except administrators have only read permissions (this is why you have to create the folders during installation). Where as changing the permissions on the commaonappdata is a bad practice you can create a folder into it and change the permissions on your folder in a desired way.

     


    My next phone is Windows Phone 7
    Wednesday, September 15, 2010 9:30 PM
  • You are storing the files at the right directory. However, you should not use the hardcode path you should use Environment. SpecialFolder  to get the path of CommonApplicationData folder.

    To get your application going perform follwoing steps

    During instalation of the application (because you will run as administrator during installation).

    1) Create a folder in CommonApplicationData such that CommonApplicationData\<CompanyName>\<ApplicationName>\SharedData

    2) Grant authenticated users Write and Read permissions on SharedData folder.

    3) Use this filder to keep files which are shared.

    Note: Creating folders in above way is not mandatory, its just a cleaner way, so that you can organize all your folders in the commonappdata. You see this problem because all the users except administrators have only read permissions (this is why you have to create the folders during installation). Where as changing the permissions on the commaonappdata is a bad practice you can create a folder into it and change the permissions on your folder in a desired way.

    Thanks for your reply.

    After postnig this question I have done some further investigation. It seems that users actually do have read/write rights in this folder, but that any new files created in that folder, are not automatically given access rights for all users. I have managed to work around this for now by assigning these rights after creating the file using the following code:

    ' grant access to all users
    Dim fi As System.IO.FileInfo = New System.IO.FileInfo(Filename)
    Dim sec As System.Security.AccessControl.FileSecurity = fi.GetAccessControl()
    Dim fsr = New System.Security.AccessControl.FileSystemAccessRule("Users", Security.AccessControl.FileSystemRights.FullControl, Security.AccessControl.AccessControlType.Allow)
    sec.SetAccessRule(fsr)
    fi.SetAccessControl(sec)
    

    This seems to work, but I've only tested it on my own development machine so far (XP). Is this likely to cause any problems with diffrerent versions of Windows or with FAT/NTFS drives, etc...?

    I haven't tried your suggestion yet of creating a subfolder and granting rights to this in my setup project. Will this get around the problem with files in the folder not having the correct permissions, or will I still need to set these explicitly each time a file is created?

    Thanks again for your help.

    Phil.

    Thursday, September 16, 2010 9:04 AM
  • I am sure that user dont have write access in common appdata, if you see that they have someone has messed up the DACLs in your computer.

    Once you create a sub folder and grant appropiate access permissions using the code above, all the files created in the folder will inherit the folder permissions unless someone explicitly changes them. You need to do anything when each file is created. You can easily test this behaviour by

    1 ) Manuually create the subfolder

    2) Change the security of the sub folder.

    3) Create file in the subfolder and check the security of the file.  


    My next phone is Windows Phone 7
    Thursday, September 16, 2010 9:41 AM
  • I have created a new standard user on my XP machine and this user can create files in C:\Documents and Settings\All Users\Application Data.

    The file I created (just by right-clicking and choosing New> Text Document) has write permission for this user but not for the Users group.

    I have done the same on a Window 7 machine, and the same applies to the C:\ProgramData folder.

    When I look at the folder properties the Users group does not have the Write permission, but when I click on Advanced, there is an additional special permission that gives "Create Files / Write Data" permission (and others).

    I don't know where these extra permissions have come from. Are you saying this is not standard? Could it be something to do with our Network?

     

    Thursday, September 16, 2010 2:54 PM
  • I see that you are right. I am not sure what the special permissions doing there. However, you should still stik to the guidelines for the application development from here http://download.microsoft.com/download/D/9/B/D9BEB875-BC1D-4338-A655-251F4F353B2E/Top10Wave.exe This doc has all you need to know about UAC.
    My next phone is Windows Phone 7 and my current browser is

    IE 9

    Thursday, September 16, 2010 3:35 PM
  •  

    Hi Phil,

     

    I'm writing to check the issue status, Please feel free to let us know if you have any concern.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, September 20, 2010 8:34 AM
  • I have modified my application to ensure that it always assigns full control rights to new files that it creates in the common application data folder. However this will only work if users have full control access rights in this folder. So what I plan to do is to take Prateek's advice, and to assign these rights to a sub-folder in my setup program. I am not quite sure what the best way to do this is. I could add some code in an installer class, similar to the code I use to set the file permissions. Is there a better way to do this though? Is there something built in to the VS2008 setup project to do this?
    Monday, September 20, 2010 10:26 AM
  • Phil,

    Have a look into Isolated Storage.


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Monday, September 20, 2010 12:05 PM
  • I've had a quick glance at a few articles on Isolated Storage. It seems that files are always restricted to the user who created them, so I don't think this is going to be useful for storing information that will be shared among users.
    Monday, September 20, 2010 2:27 PM
  • Isolated storage can restrict files to either the user that creates them.... or the application (the assembly) that creates them. In other words all users of the application. Wouldn't have recommended it big man if it wouldn't work.

     


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Monday, September 20, 2010 3:33 PM
  • Are the following articles both wrong?

    http://msdn.microsoft.com/en-us/library/eh5d60e1%28v=VS.80%29.aspx

    "Access to isolated storage is always restricted to the user who created it"

    http://devcity.net/articles/42/1/isolatedstorage.aspx

    "Both types of isolation require that the storage area be associated with a user and assembly."

     

    Monday, September 20, 2010 3:56 PM
  • Yes.

    You can get machine scoped Isolated Storage for an assembly using the IsolatedStorage.GetMachineStoreForAssembly() method.

    If you deploy with ClickOnce you can use IsolatedStorage.GetMachineStoreForApplication.


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Monday, September 20, 2010 4:28 PM
  • Yes.

    You can get machine scoped Isolated Storage for an assembly using the IsolatedStorage.GetMachineStoreForAssembly() method.

    If you deploy with ClickOnce you can use IsolatedStorage.GetMachineStoreForApplication.


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)


    Yeah well actually .. to be honest I'm not sure now! I was sure but I'm not any more.

    I'm convinced GetMachineStoreForAssembly() will store the data for the assembly at the machine level (all users).


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Monday, September 20, 2010 4:41 PM
  • Yes. It works at machine level. Users can share the data. Tested it.
    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Monday, September 20, 2010 4:56 PM
  • Hi Phil,

    Thought about this some more yesterday and you'll want to check something. Isolated storage works by using the evidence of the assembly (probably it's strong name will play a part) to identify the storage the assembly needs. This means you might have versioning issues :\  for example v1 of an assembly will be able to read the files but v2 might not!!! 

    It will work but whether you should use it. That's a different matter.

     

     


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Tuesday, September 21, 2010 8:11 AM
  • Thanks Derek,

    I will look further into Isolated Storage when I get a bit more time. For now I think I'll stick with putting files into the application common data folder, and make sure I set the necessary permissions in my installer class.

    Cheers,

    Phil.

    • Marked as answer by eryang Wednesday, September 29, 2010 1:32 AM
    Tuesday, September 21, 2010 8:48 AM
  • Thanks Derek,

    I will look further into Isolated Storage when I get a bit more time. For now I think I'll stick with putting files into the application common data folder, and make sure I set the necessary permissions in my installer class.

    Cheers,

    Phil.


    Yeah that would be the safest option. Had the same problem as yourself quite recently, sharing a configuration file, but this time in VBA code. Couldn't believe the AllUsers profile was read only for the most users. It was really annoying and some what counter intuitive. Yeah your approach is the best approach. :) See you later.

    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Tuesday, September 21, 2010 10:15 AM
  • Thanks Derek,

    I will look further into Isolated Storage when I get a bit more time. For now I think I'll stick with putting files into the application common data folder, and make sure I set the necessary permissions in my installer class.

    Cheers,

    Phil.


    Yeah that would be the safest option. Had the same problem as yourself quite recently, sharing a configuration file, but this time in VBA code. Couldn't believe the AllUsers profile was read only for the most users. It was really annoying and some what counter intuitive. Yeah your approach is the best approach. :) See you later.

    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    Tuesday, September 21, 2010 10:15 AM
  •  

    We temporarily mark a reply, please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, September 29, 2010 1:32 AM