Question

I posted this question a while ago regarding where to store non-user specific application data on Linux.

As you can see, I intended to use “/Library/Application Support” on Mac and perhaps “/var/lib” or “/usr/share” on Linux.

On an existing application (currently Windows only) we use “\ProgramData” on Vista & Windows 7 and “\Documents and Settings\All Users“ on Windows XP (both obtained using System.getenv(“ALLUSERSPROFILE”), which does not work on Mac or Linux).

The problem I am finding with the Mac & Linux locations (unlike the Windows ones) is that they are not accessible by non-root/admin users, which sort of defeats the purpose of using them.

What is the best practice is this case? We could simply store the application data in the user’s home directory. I wouldn’t actually be dead against this, as it seems reasonable for the application to appear completely ‘new’ when a new user tries using it. The main problem this gives us is that each user would have to enter the serial number in order to activate the application (the activation info is part of the ‘application data’ we need to store). This isn’t really ideal.

That said, if there is no real alternative then I suppose it will have to do.

Answer 1

What do you mean by non-user specific application data?

• Read-only resources needed by application, such as localization strings or button icons:

  • on Mac they are stored in application bundle itself, in Resources subfolder
  • on Linux, they can be stored near application binary, in /opt/<app>/etc for instance.

• Read/write properties, such as serial number:

  • you can consider this information as user-specific application data, so it should go somewhere in $HOME directory
  • you can consider this information as computer-wide application data, in which case its setting should be perfomed during software installation process, i.e., with administrative privileges.