CODEWITHSUNDEEP
javalinux
William
William

Reputation: 13642

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

In my OSGi-based Java application 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:

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

Upvotes: 82

Views: 84946

Answers (8)

david1024
david1024

Reputation: 131

According to 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.

Upvotes: 3

starblue
starblue

Reputation: 56832

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

There isn't any guarantee for completeness. Please check the Filesystem Hierarchy Standard.

Upvotes: 67

Rob Hruska
Rob Hruska

Reputation: 120456

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 run time.

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.

Upvotes: 121

Steve K
Steve K

Reputation: 19596

Since you are using Java, look 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.

Upvotes: 7

James R. Perkins
James R. Perkins

Reputation: 17840

You could use the System.getProperty("user.home") to get the users home, so it's more platform independent.

Upvotes: 0

catwalk
catwalk

Reputation: 6476

In the /usr/share or /usr/local/share folders.

Upvotes: 2

Locksfree
Locksfree

Reputation: 2702

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

Upvotes: 0

Pascal Thivent
Pascal Thivent

Reputation: 570645

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.

Upvotes: 6

Related Questions