I'm developing a cross-platform desktop application for Mac, Linux and Windows. The application will create a plain-text log file to help with debugging, amongst other things. What are people's recommendations for a sensible place to store the log on each of the platforms?
Here is my guess so far, based on web searches:
Mac: ~/Library/Logs/MY-APP-NAME/system.log
Linux: ~/.MY-APP-NAME/logs/system.log
Windows: %APPDATA%\MY-APP-NAME\logs\system.log
For Linux, the XDG Base Directory Specification is followed by some applications. Log files are not specifically called out as such. You can put them either into a subdirectory of the data directory ($XDG_DATA_HOME or $HOME/.local/share), where they will not be deleted automatically, or you could use a subdirectory of the cache directory ($XDG_CACHE or $HOME/.cache). In the latter case, the files could be automatically expired after some time.
Related
I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).
Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.
I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.
My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.
Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)
Not really.
The directory that serves as a common
repository for application-specific
data for the current roaming user.
AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.
You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).
You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.
If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.
If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData
You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.
Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?
Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.
On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.
It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of
%userprofile%\AppData\Local\Programs\Microsoft VS Code
This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation
Windows 7 folder structure is deeply inspired on Unix structure:
/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user
Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).
It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.
When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.
Please install executable files to the %programfiles% folder in Windows - a simple MSI based install package can perform an active setup for any new user who logs onto the machine to create the user specific files and folders in their profiles %appdata% folder. You see this behaviour for Internet Explorer, Adobe reader, etc. - It's the little MSI installer window that pops up the first time you log onto a machine which has those applications installed. - Thanks - a system admin :)
My opinion, for what it's worth, is that user-specific program files is just asking for trouble and is a damn stupid thing to do.
A much more sensible approach is to install different versions of your program to:
\Program Files\Your Program\Program_v0.1\Program.exe
\Program Files\Your Program\Program_v0.2\Program.exe
\Program Files\Your Program\Program_v0.3\Program.exe
\Program Files\Your Program\Program_v0.4\Program.exe
I would then place a bootstrapping launcher at:
\Program Files\Your Program\ProgramLauncher.exe
Then, the user application data folder will only contain data, including an INI/XML/Settings file that indicates the version of the program that this user is working with.
Such an approach satisfies the core tenant of keeping data and executing code separate, allows every user to run a specific version of the code, and offers a small amount of de-duplication by ensuring the same executable code is not copied multiple times across user folders.
Otherwise, go right ahead with installing programs to AppData and undoing the years it has taken us to achieve clean separation of code and data. I found this thread because I noticed that Chromium and DropBox are installing code to AppData. I'm going to uninstall those program, and change the permissions on my AppData folder to exclude execution to ensure I can easily spot other programs attempting the same BS.
I'm looking for a documentation which describes the standard way of setting up a Node.js server. I'm wondering whether there is such a thing, actually.
I'm writing a Linux (Ubuntu) server and administrators of a standard server would find it normal to find the settings of the application under:
# Admin editable settings
/etc/<app-name>/<app-name>.conf
# Read-only files used by the server
/usr/lib/<app-name>/...
# Read-Write files used by the server
/var/lib/<app-name>/...
The <app-name>.conf file could be used to change the other paths.
Does the default Linux organization sound completely out of wack for a Node.js application?
IMPORTANT: I'm not in any way interested about how to read the .conf or what format it should be in. That part already works exactly as I want it to work. I'm only interested in where those files are expected to be installed when someone installs your Node.js service.
I'll try to keep this question short, but it is in 2 parts, please:
Where should config files for nodejs/npm CLI tools be saved?
What should they be called?
Let's say I write a node.js CLI tool that, for example, grabs today's weather and displays it in terminal. I call it weather-getter. Note, the main goal is not to be called programmatically, but typed into terminal like BASH. It is intended to be run by typing its simple name after installing globally, or via a directory in the user's local /bin. (Sudo is not required for its install.)
This project would be installed normally via npm. It can receive a zipcode via an argument like:
gavin#localhost:~$ weather-getter -z "12345"
OK the program works fine like this. My next step would be to allow the user to save a config file somewhere, and pull from that config file for defaults. Similar to a .vimrc file. This config might look like this:
{
"zipcode": "12345",
"language": "en",
"unit": "fahrenheit"
}
I suppose it should begin with a dot. I also suppose it should be located in the npm module install, and not in ~/. Or should I consider using ~/ or /etc/ or ~/.config or ~/.local like many other programs? Should node programs try to use a common directory, such as ~/.config/node/ or ~/.config/npm/? And if the file is in there, should it begin without the dot?
Note: My question is not about reading/writing a file with node.js, just recommendations on the config location and naming convention. Thank you!
Since this is a generic CLI application (which only so happens to be implemented in Node.js) installed into the system path, you should follow the best practices or rules established for the target operating system.
Unix/Linux/OS X, similar
In order of priority, these would be (but are not limited to):
~ (User's home folder) - many programs store user-level config in their home directory, usually in a dot-prefixed file, followed by the application's name (or similar) - i.e. ~/.weather-getter
/usr/local/etc, /etc - system-level configuration files. These should generally apply to all users in the system and thus should take less precedence than settings in home folder. The difference between these two etc paths is usually that the former is used for user-installed programs, whereas the latter is for system-level programs (this is especially true for Mac users using Homebrew). This distinction is, however, not always respected and therefore both locations should be checked for config files (preferrably with the /etc directory having lesser priority).
Your application's root - these should be the default settings for your application, a fallback when no user or system config has been found.
Other locations may be considered if needed.
Windows
This is usually somewhere within %APPDATA% directory if your app allows GUI or at least CLI configuration management, or the Windows registry (using winreg, for example). I have personally little experience with Windows development/CLI so I welcome any further comments or answers on this topic. I believe using the user's homefolder would also be acceptable as long as the file can be marked as hidden (so it does not clutter the view).
Some general considerations
Many CLI applications install their default configurations into one of the mentioned locations so the user has a good starting point when configuring your app
The way your configuration options are treated when multiple configuration files are present (are they merged in some order? Is only one used? Which one takes precedence?) is completely up to you, but you should make it clear in your documentation, perhaps even mention it in the configuration files themselves
If your application requires multiple configuration files it is preferred that they are grouped in their own folder
Update about dotfiles
The reason why some files or folders are prefixed with a dot is to hide them from users' normal view (i.e. when browsing their home directory via a GUI). It is therefore common practice to use dot-prefixed file/folder names when storing configuration files in directories where users normally operate, but not do so when storing config files in system-level folders.
The ospath package has a function data() which returns a sensible location for such files for each of the major platforms.
This is a more general and noob question. I am developing a small application in Linux (Ubuntu, to be more precise) and at this point I have an executable, a shared library (.so), a configuration file (.conf) with some settings to be read by the application at the beginning, a data folder with images and other resources to be used during the application life-time (resources that can be also modified, deleted) and of course, I would need some file for logs and messages (right now I am using syslog).
So, my question is, where should each one of these be stored when the application is installed on a client's computer? What is the standard way of organizing all the application's files in Linux? On Windows everything would be found usually in the C:\Program Files\(App Folder) but it looks like on Linux things are more (or less) organized. Can you give me some advices on this matter?
Program data were historically stored in dot-prefixed folders in user's home directory. Modern Linux distributions tends to use ~/.config/program_name folder.
For all files that will not be modified after distibution follow Linux standard:
Ex: project dir: ABC
sub directories:
logs - keep log files
conf - keep configuration files here
bin - executable binaries here
traps - any trap mesg
then depend on what application we develop
Along with you can set level for starting your application from boot level if required.
Let say i have a cross-platform runnable application
This application create then read/write some data and preference in external files
Bundle hierarchy is as follow:
ApplicationFolder/application.jar
ApplicationFolder/database.odb
ApplicationFolder/config.xml
Whether it's on a Mac, Windows or Linux, the application knows that everything is next to her (ie: /database.odb or /config.xml)
Now comes the Self Contained Application feature provided by JavaFx 2
The application is embedded in .exe on Windows, .app on Mac and don't know yet about Linux...
As a Mac user i've tested it on Mac and saw that database.odb and config.xml are now created at the user root path
I thus agree that i should think of a cross-platform mechanism to save/read my application preferences regarding the operating system
But i'm not quite sure of what to do and how to do it (can't find any googling help either..)
On windows, the .exe is installed in a folder, so i guess i can keep the same behavior
On Mac, the .app is a folder and i should keep everything inside (how to get the .app path ?!)
Isn't there a built-in mechanism in Java/JavaFx ?
Thanks a lot for any comment, advice, documentation or else that you could give me
Badisi
There are many ways to do this. I have listed some of them here in no particular order. The recommended approach depends on the type of data being stored.
Java provides a couple of mechanisms (e.g. the properties API and the preferences API) for maintaining application preferences.
If your application is sophisticated enough to benefit from an database, then you might want to use Java EE or Spring, both of which have their own configuration mechanisms.
For read-only configuration, you can bundle the relevant files inside your application jar.
To store customized application configuration files or client application wide databases in relative to the application jar, write the required files at runtime. See How do I get the directory that the currently executing jar file is in?.
For user specific configuration, use System.getProperty("user.home") to retrieve the user's home directory, then create a subdirectory for your preference storage (for example "{$user.dir}/.myapp") with hidden file attributes so that it doesn't show up on a standard file directory list.
If your app relies on internet connectivity, then you can store some of this information server side rather than the client and make use of it from the client using internet protocols. An advantage of this approach is that user configuration and data is automatically ported across client machines.