Home » Linux » Where to store application data (non-user specific) on Linux

Where to store application data (non-user specific) on Linux

Posted by: admin November 29, 2017 Leave a comment

Questions:

In my OSGi-based Java app I am developing a bundle to provide the rest of the system with access to the file system. In addition to providing access to the user home directory, I also wish to provide access to a non-user specific area. Exactly what this area will be used for is as yet undetermined, but it will not be for preferences (handled by a different bundle), however it may be used to store data that could change at runtime.

I intend on using the following directories for this purpose:

  • Windows Vista & Windows 7: “\ProgramData”.
  • Windows XP: “\Documents and Settings\All Users“.
  • Mac OS X: “/Library/Application Support”.

Where is a sensible equivalent in Linux and how do I get a handle on it from my Java code?

Answers:

It depends on what kind of data you’re planning on storing. This answer is under the premise that you’re storing and modifying data at runtime.

Contrary to what others have suggested, I would recommend against using /usr/share for storage. From the Filesystem Hierarchy Standard:

The /usr/share hierarchy is for all
read-only architecture independent
data files.

As you’re modifying data, this goes against the read-only nature of the /usr subsystem.

A seemingly better place to store your application state data would be /var, or more specifically, /var/lib. This also comes from the Hierarchy Standard. You could create a /var/lib/myapp, or if you’re also using things like lock files or logs, you could leverage /var/lock or /var/log.

Have a deeper look at the standard as a whole (linked to above) – you might find a place that fits what you want to do even better.

Like Steve K, I would also recommend using the Preferences API for application preference data.

Questions:
Answers:

It depends.

  • Global configuration -> /etc/appname

  • Read-only, independent of machine architecture -> /usr/share/appname

  • Read-only, machine specific -> /usr/lib/appname

  • Read-write -> /var/lib/appname

No guarantee for completeness, please check the Filesystem Hierarchy Standard.

Questions:
Answers:

Since you are using Java, have you looked at the Preferences API?

From the introduction:

Applications require preference and configuration data to adapt to the needs of different users and environments. The java.util.prefs package provides a way for applications to store and retrieve user and system preference and configuration data. The data is stored persistently in an implementation-dependent backing store. There are two separate trees of preference nodes, one for user preferences and one for system preferences

I’d let the built in API do the work.

Questions:
Answers:

The freedesktop.org (previously known as the X Desktop Group) project has defined some standards for this in the XDG Base Directory Specification.

In your case, I’d have a look at $XDG_DATA_DIRS:

$XDG_DATA_DIRS defines the preference-ordered set of base directories to search for data files in addition to the $XDG_DATA_HOME base directory. The directories in $XDG_DATA_DIRS should be seperated with a colon ‘:’.

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

I warmly suggest to read the XDG Base Directory Specification.

Questions:
Answers:

In /usr/share or /usr/local/share folders

Questions:
Answers:

If it is non user specific, you can probably store it under /usr/share/appname

Questions:
Answers:

I know this is an old question, but according to https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
(which seems to be updated and correct as of July 2015)…

Assuming that the datafiles are understood to not meet the requirements of /tmp or /var/tmp then /usr/local/share/theApp or /usr/local/theApp.

Questions:
Answers:

Do you want to hard-code it like that. You could use the System.getProperty(“user.home”) to get the users home so it’s more platform independent.