Daemon: Store blockchain in '~/.local/share/bitmonero' by default

[mj-xmr]

Resolves 3727 (Only the data part of it)

The default storage path for blockchain is being switched from ~/.bitmonero to ~/.local/share/bitmonero under Linux, and from ~/.bitmonero to ~/Library/Application Support/bitmonero under MacOSX.

If XDG_DATA_HOME if found, it's preferred over everything else.

[selsta]

Does this handle backwards compatibility?

[mj-xmr]

Does this handle backwards compatibility?

Short answer: no

It only sets the default directory. If the user chooses via command line to use a different directory, then this code won't have any effect. OTOH, if the user doesn't set the data directory explicitly nor moves the ~/.bitmonero down to ~/.local/share/bitmonero prior running this version, then the whole blockchain will be re-downloaded to the new directory.

[mj-xmr]

@selsta : My proposal for retaining backward compatibility would be the following:

• rename the original std::string get_default_data_dir() to deprecated_get_default_data_dir(), keeping its content intact
• inside the new implementation of get_default_data_dir() I'd call the deprecated_get_default_data_dir() and test if the directory exists. If yes, use it and write a warning in console for the user to consider moving the obtained, previous directory to the directory pointed by the new get_default_data_dir(). If the previous directory doesn't exist, then just silently use the new directory.

Shall I go in this direction?

[selsta]

Shall I go in this direction?

Sounds reasonable.

[selsta]

Also we should maybe discuss this in the next dev meeting. Changing the default location might end up in confusion as every user is aware of ~/.bitmonero now.

Honestly as a Mac user I can never find stuff inside Library/Application Support, even though it is a standard :D I have to google it every time.

[mj-xmr]

OK, let's discuss it. The latest commit brings the backward compatibility, as described in my previous comment.

Honestly as a Mac user I can never find stuff inside Library/Application Support, even though it is a standard :D I have to google it every time.

I get ya. I can settle with .local/share/bitmonero for OSX.

[ndorf]

If we're changing it anyway, why not make it .local/share/monero?

[mj-xmr]

If we're changing it anyway, why not make it .local/share/monero?

This complicates the transition a little bit, since I need an another variable for the "monero" string, alongside the ".bitmonero", which has to stay there for backward compatibility.

That said, I also find it reasonable, if you ask me.

[moneromooo-monero]

This seems annoying for no good reason. The claim is the first post that it "fixes" something is disingenuous since the report does not report a bug, just a preference.

[mj-xmr]

This is simply how you link an issue to a PR.

[iamamyth]

This seems annoying for no good reason. The claim is the first post that it "fixes" something is disingenuous since the report does not report a bug, just a preference.

I agree that this seems like needless churn. I would favor enabling support for XDG_DATA_HOME, but not changing the existing default in other cases. It's worth noting that, per Linux filesystem standard the newer XDG specification isn't mandatory, and the current approach is perfectly acceptable:

3.8.2. Requirements

User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a "dot file"). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character. [8]

3.8.3. Home Directory Specifications and Conventions

A number of efforts have been made in the past to standardize the layout of home directories, including the XDG Base Directories specification [9] and the GLib conventions on user directory contents. [10] Additional efforts in this direction are possible in the future. To accomodate software which makes use of these specifications and conventions, distributions may create directory hierarchies which follow the specifications and conventions. Those directory hierarchies may be located underneath home directories.

As for this matter:

This is simply how you link an issue to a PR.

I suggest "resolves" in cases like this one, where there's no bug, but rather, a feature request.

[mj-xmr]

I suggest "resolves" in cases like this one, where there's no bug, but rather, a feature request.

Done

[ghost]

Is this still up for merge?

[mj-xmr]

Hi @digitalwtf ,

As far as I can see, there's nothing technical that would prevent anybody from merging it:

The only reason that I can imagine why it's not merged at all, is the few decisive persons' prioritizing issue - namely all focusing on a single thing only all the time and calling it "diversity".

[jtgrassie]

@digitalwtf The reason it's not yet merged I suspect is because it doesn't appear to have strong enough support.

@moneromooo-monero and @iamamyth make good arguments against merging:

This seems annoying for no good reason. The claim is the first post that it "fixes" something is disingenuous since the report does not report a bug, just a preference.

I agree that this seems like needless churn. I would favor enabling support for XDG_DATA_HOME, but not changing the existing default in other cases. It's worth noting that, per Linux filesystem standard the newer XDG specification isn't mandatory, and the current approach is perfectly acceptable

The suggestion to enable/support XDG_DATA_HOME but not change the rest, seems the most sensible and least invasive approach.