none
Sharing Data under [CommonAppData]

    Question

  • Is it against Logo Certification if we install data to [CommonAppData] in a subdirectory we create and set permissions of our directory for Full Control for everyone?

    We want to share data between all users and allow those users each to modify that data.  If we're not allowed to modify the folder permissions, what is the correct "Logo Certified" way to share files between users?

    ...Matt

     

    Friday, March 16, 2007 9:22 PM

All replies

  • Setting Full Control for Everyone is a massive security hole, don't do that under any circumstances. If you must change permissions, you should grant Modify rights to the Users group. I believe this is a Logo failure, though I can't find a definite statement one way on the other.

    The only way I can see to share data between users is to broker the operations via a service which can perform the necessary security/transaction checks, assuming it is something which can't be handled sufficiently via a temporary elevation (either because it is too frequent or may need to be changed by limited accounts).

     

    EDIT: This does not constitute a Logo failure.

    Sunday, March 18, 2007 9:01 PM
  • Matt,

    Office 2007 carries the Vista Logo Certification. It creates and uses a folder under ProgramData\Microsoft\Office called Data. The Data folder is preset on install to allow Everyone the following permissions: modify, read and execute, list contents, read, and write.

    Based on the above it looks like creating a subfolder under ProgramData with Everyone having the above rights must be an okay thing to do.

    Passing the certification test is very cut and dried. Your app either passes the 32 test cases or it does not. The Vista logo spec and test cases don't leave many questions unanswered.
    Monday, March 19, 2007 4:13 AM
  • Windows Vista

     

    Surely there has to be somewhere an application can store its configuration data in such a way that all users of the computer are using the same configuration data.

     

    As well as shared folders, Is there somewhere/somehow that an application can store data in the registry so that the data is available when the same application is used by other users ?

     

    I don't want my application to programatically change permissions (or shell out to cacls (icacls)) and I don't want my users having to fiddle with folder permissions either.

     

    surely MS accepts that some users do want to share their data  ? Yes, but Where ?

     

    If my application creates a new folder in the root of the C: drive such as c:\myapp that folder is currently acessible to all users. Will that change in future releases of Windows ?

     

     

    Thursday, May 03, 2007 8:21 PM
  • If it is just sharing documents, then users themselves can save them in the public documents folder if they wish to share them.

     

    Configuration data is a bit different, it raises all sorts of messy issues - What happens if two users are running the app at the same time? How do you stop one user breaking the configuration of others? How do you keep configuration settings consistent when a user has a roaming profile? - all of which you as a developer really need to think about.

     

    99% of the time it's much, much better to allow individual users to have there own personal configuration stored in their own profile. Of course you sometimes want an Administrator to be able to enforce certain settings or particular configurations, for those you can keep an additional setting in a per-machine location which is checked first and overrides per-user customization. Ideally this would be in a Group Policy controllable registry location.

     

    As for dumping data folders in the root of the drive, I'd strongly advise against it. It's untidy, prone to users accidentaly deleting it and may very well break in certain configurations.

    Friday, May 04, 2007 9:00 AM
  • Thank you Andy,

     

    My application is 'multi-user' aware. For example the application might show data in a grid. One user might drag the column widths to his preferred setting which the app stores in the config database in records identified by that user's login name so that when that user returns to the same grid the columns are sized to his preferred widths. This data wouldn't 'break' if the config database got virtualized the user wouldn't notice. The machine would just end up having config databases scattered across different user's virtual storage areas. So, it isn't too bad that this data gets vrtualized. However, I'd prefer it if is was all in one file so if the application is migrated to another computer then my automatic backup/restore prodedures can take car of that.

     

    The main problem is the data that the application creates. The application is an inventory manager database. User-A comes to work in the morning. Creates/updates inventory, purchase orders etc and then he goes home when he's done his 8 hours. User-B then comes on duty, using the same computer, starts the inventory program and, because of the virtualization, he can't see any of the work done by his colleague.

     

    What is the 'standard' microsoft recommended way to 'share' the application data in this way. Both users really MUST have access to the same data. My scenario is not unique. It must be very common.

     

    Thanks in advance for any assistance.

    Friday, May 04, 2007 11:19 AM
  • Since the users don't directly open/save the database, the best approach is indeed to create a folder with appropriate permissions under CommonAppData. This will not fail Logo tests (I hadn't checked when I wrote that earlier message above so apologies if that was misleading).
    Friday, May 04, 2007 11:30 AM
  • Thank you once again.

     

    I forgot to mention that my application is distributed as a setup/installer package. The user/installer isn't expected to do things (or even know how to do things) such as change permissions on files or folders. My application would need to do that automatically during installation or on first use and then be able to determin whether it was done successfully. Could you point me at some information about programatically changing/checking folder permissions ? (Using Win32 functions rather than shelling out to external programs such as 'cacls')

     

    Thanks

     

    Friday, May 04, 2007 11:42 AM
  • If you are using Windows Installer, it can be done with the LockPermissions table.

     

    As for doing it in Win32 directly, there is plenty of sample code on the web such as here, here or here.

    Friday, May 04, 2007 12:20 PM
  • Thanks. That ought to do it.

     

     

    Friday, May 04, 2007 1:30 PM
  • During installation I now create a common app data folder with permissions which allows normal users to read/write the same database files without virtualization. So, everything works just fine now. Thanks for the assistance.

     

    What I'd like to do though is add some error trapping. If the permissions on the folder were changed back or for some reason didn't get set in the first place then virtualization starts happening again.

     

    I don't want virtualization. Even microsoft says that we should not rely on it. So, if for some reason the app couldn't write to the common data folder then I would prefer it that windows simply displayed a message saying that the user did not have permission.

     

    I assumed that using a manifest with something like -

     

    <requestedExecutionLevel
    level="asInvoker"

     

    - would tell vista that the app is vista aware and does not want virtualization to take place.

     

    But virtualization still takes place.

     

    What can I do to make sure that virtualization does not take place. If my app tries to write to areas where it's not allowed then I want the write to be prevented and user to be told. I don't see the point in virtualization.

    Saturday, May 05, 2007 7:20 AM
  • It sounds like your manifest isn't being recognized correctly. Are you sure it has no errors in it?
    Saturday, May 05, 2007 7:15 PM