Move MC config files to ~/.mc instead of multiple places in $HOME

[h4tr3d]

Hi!

It is bad new about moving configs and other files of mc into ~/.config, ~/.local, ~/.cache.

This paths needs by XDG compliant applications, but XDG is X Desktop Group and MC does not only a "X Desktop" application. It can be run in pure console, on servers, routers & etc.

So... It a bad idea to move configs from single place into multiple places and old behaviour is requered without any hacks like mc-wrapper.sh or symlinks into ~/.mc

Discussion is open now. Voting also.

[gotar]

RTF#1851 and just set proper XDG_* variables. Following a standard with letter 'X' doesn't mean it's X-related in ANY way, except working group _name_.

I see no discussion here, you've said "it's bad because it's bad" only, that's hardly an argument.

[sergem]

I'm not sure what original bugreporter asked for, so I'll make a guess.

---

mc 4.8.0 violates fd.o standard, because it puts files in directories that they do not belong to.

In particular it puts filepos, history and panels.ini into .cache. According to standard only non-essential data files should be stored there - files, that can be safely deleted and would be regenereted automatically if missing, like avatars for IM clients, or files previews for graphical file managers. But files that mc 4.8.0 puts there (filepos, history, panels.ini, ...) are essential parts of mc that cannot be regenerated if missing. They should belong to the .config directory, but not .cache.

Same about .local/share. Files, that mc currently puts there (mc.ext, edit.*.rc...) are definitely configs, and they're mc-specific. They're not shared with any other programs, and should not be in share directory. Also as for mc user, for me it's really not obvious, that mc-specific association config appears in .local, I would expect to see it in .config directory.

Steps to reproduce:
start mc 4.8.0

Expected result:
all configs are in .config

Actual results:
some configs are in .local/share, others are in .cache

This is a regression in usability, or if you prefer that, a violation of fd.o standard.

Suggestion: Put all configs back into the same directory, let it be XDG-compliant .config/mc. Optionally move /tmp/mc-username to .cache/mc. Currently mc has no files shared with other programs, so nothing should be written to .local/share.

---

How about such bugreport? h4tr3d, is that what you asked for? gotar, how about such change?

[trialuser]

I agree with reporter. mc is the command line program and should store configs like ssh, lftp, moc, mpd and others.

[gotar]

Replying to sergem:

I'm not sure what original bugreporter asked for, so I'll make a guess.

He wants config files moved back to ~/.mc, just because this is the way it was for years. This is nothing more than effect known in psychology under the term of 'cognitive dissonance', which makes people not accept any changes, even if their fears are groundless and have no arguments other than 'that thing was here/like this since I remember, so it MUST have been good'.

---

Suggestion: Put all configs back into the same directory, let it be XDG-compliant .config/mc. Optionally move /tmp/mc-username to .cache/mc. Currently mc has no files shared with other programs, so nothing should be written to .local/share.

---

How about such bugreport? h4tr3d, is that what you asked for? gotar, how about such change?

I agree with these arguments - XDG_CONFIG_HOME should be used for all the config files.
About /tmp/mc-username to .cache/mc I'm not sure - might VFS decompressed files be considered cache? I don't think so, they are purely temporary, so TMPDIR shall be used.

[gotar]

Replying to trialuser:

Again - read the former #1851 please. It has NOTHING to do with server/workstation/CLI/GUI/TUI/colour/alphabet/purpose or anything else. If other apps put trash in your home directory, patch them or don't use them. And FYI: .ssh directory must be strict because of public key authentication.

[trialuser]

Replying to gotar:

Replying to trialuser:

Again - read the former #1851 please. It has NOTHING to do with server/workstation/CLI/GUI/TUI/colour/alphabet/purpose or anything else. If other apps put trash in your home directory, patch them or don't use them. And FYI: .ssh directory must be strict because of public key authentication.

Again, no reasonable arguments. It's sad.

[slavazanko]

Okay, can I make the summary of this holywar?

All files should be plased just in one directory: ${XDG_CONFIG_HOME}/mc

Right? Or is anyone wants to return files to ${HOME}/.mc?

[gotar]

Replying to trialuser:

Again - read the former #1851 please.

Again, no reasonable arguments. It's sad.

Click here >>>#1851<<<. The number #1851 is the right thing to click. Do not click >>here<< nor >>there<<, click the ticket number and read. You shall not click outside this frame, focus on frame inside. Use The Number to follow into arguments. If you don't want to rewind, you might as well click here #1851.

[gotar]

Replying to slavazanko:

Okay, can I make the summary of this holywar?

It's not a war: .config/mc is nothing worse than .mc except some psychological effect I've mentioned above. It is only better:

• separates user files (valuable itself) from user configurations,
• eases clearing configuration,
• eases backups,
• etc.

The rationale is exactly the same as in XDG, so this is not the place to discuss this. Moreover it is supported by glib, so there's no additional overhead.

The only thing against is someone's habit. The Holywar requires throwing arguments from both sides:)

All files should be plased just in one directory: ${XDG_CONFIG_HOME}/mc

I'm not sure if all - how about mcedit cooledit.* or Tree?

[h4tr3d]

Replying to slavazanko:

Okay, can I make the summary of this holywar?
All files should be plased just in one directory: ${XDG_CONFIG_HOME}/mc
Right? Or is anyone wants to return files to ${HOME}/.mc?

Ok, It can be compromise way. MC internally does not fully XDG compliant: it does not share any data with other apps, so ".local/share" is not needed, it does not use persistent caches, so ".cache" is not good place for realy mc-temp files. In this situation placing configs and other mc-related files in multiple places in home directory with long pathes looks like bad idea.

Contrariwise storing apps-specific configs (and other files) in one place comfortably to backup, testing new versions and moving configs across different machines (especially via network/ssh).

[trialuser]

Replying to gotar:

Replying to trialuser:

Again - read the former #1851 please.

Again, no reasonable arguments. It's sad.

Click here >>>#1851<<<. The number #1851 is the right thing to click. Do not click >>here<< nor >>there<<, click the ticket number and read. You shall not click outside this frame, focus on frame inside. Use The Number to follow into arguments. If you don't want to rewind, you might as well click here #1851.

Was it trolling? I already have read this ticket and found nothing interesting. What problems should be fixed by this directory structure? XDG compliance? "reduce .files mess and clean up $HOME"? I see that second argument is not true. A lot of files in different places looks like a bad joke. Also mc is not X Desktop application.

[sergem]

Replying to gotar:

I'm not sure if all - how about mcedit cooledit.* or Tree?

cooledit.clip is not a cache file, since it cannot be regenerated if lost. It's more like a history. And angel_il said in jabber that he would be very disappointed if this file is lost. But it looks you're right about Tree.

Replying to h4tr3d:

It can be compromise way. MC [...] does not use persistent caches, so ".cache" is not good place for realy mc-temp files. In this situation placing configs and other mc-related files in multiple places in home directory with long pathes looks like bad idea.

Actually, as gotar pointed out, there's one cache file in mc - Tree cache. But creating the directory just for that single rarely used file does not make much sense. So putting all files in .config/mc looks like a reasonable compromise to me as well.

Replying to trialuser:

A lot of files in different places looks like a bad joke.

Right. How about a lot of files in a single directory .config/mc? They would be still easy to find, but will also become easy to backup. Additionally, if you want to test different versions of mc, that would allow you to switch mc configuration on the fly by changing XDG_CONFIG_HOME.

[god12]

I think 'Tree' should be in .cache (and as far as I understood it's the only cache file ATM).
The rest seems to belong to ${XDG_CONFIG_HOME}/mc except temporary files in /tmp/mc-user.
.local/share should be empty cause mc share nothing with any program.

Users wishing to preserve old behavior can start mc like:
XDG_CONFIG_HOME=$HOME/mc mc
and(or) by creating appropriate symlink.

[ossi]

'Tree' is cache data, indeed.

for the VFS and other temp files, see the somewhat recent addition of $XDG_RUNTIME_DIR to ​http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

.local/share has nothing to do with sharing between applications. the name derives from the FHS /usr/share and refers to sharing between architectures. in the case of the location in $HOME, it is pretty much the same as .local/lib (as one cannot have machine-specific mounts inside the home directory anyway).
it is the correct location for all working data which does not qualify as configuration. consequently, the clipboard, filepos and history do belong here.

the ini, ext and everything else which is really configuration belongs to .config.

i don't really care whether the files are in ~/.mc or the XDG dirs, but if the latter is used, it should be done in a standard-compliant way.

[sergem]

Replying to ossi:

for the VFS and other temp files, see the somewhat recent addition of $XDG_RUNTIME_DIR

It's not for temporary files. It's for pid-files and sockets/pipes.

it is the correct location for all working data which does not qualify as configuration. consequently, the clipboard, filepos and history do belong here.

Well, it depends on what you call "configuration". Default character set for files, display format for panels, content of Alt+H list, and text inserted on Shift+Insert hit - they all look like configuration to me.

.local/share has nothing to do with sharing between applications. the name derives from the FHS /usr/share and refers to sharing between architectures (as one cannot have machine-specific mounts inside the home directory anyway).

HOME can easily be on NFS shared between architectures. And anyway, if .local is derived from /usr there should also be .local/lib, .local/bin, .local/libexec, .local/include... But there's only .local/share there. My understanding of the standard is that standard was created to put a common ground for communications between programs. Before that to create a new menu entry you had to make an entry for every existing WM in its own directory using its own format. So the standard came, and now users can place icons to .local/share/icons and every program will find them there. They also can change configuration for a .desktop entry in .local/share/applications and any DE/WM will apply new configuration. At least this makes sense.

How else you can explain, why files from single .mc directory should be placed into different directories across home? I mean, what benefits it brings to mc users? For example:

1. The main reason this feature was asked for is to reduce .dotfiles mess in HOME. But mc is also used on servers with no X-applications, so there's no .config, .local and .cache directories there. Having a single directory .config/mc instead of single .mc does not change anything, but having three directories .config+.local+.cache there will actually increase this mess instead of reducing it.

2. Putting all files to .config/mc makes them easy to remove, if I decide that I'm tired of mc and want to delete it from my system and clean all the remains. Putting them to separate directories makes me crawling across my HOME and searching where else mc could place its files.

3. Putting all files to .config/mc makes it easy to backup all mc configurations before major mc upgrade and, if anything goes wrong, allows to fall back to previous version and easily restore all the configurations. Both backup and restore become pain when files are in different directories.

4. Having all config files in .config/mc allows me to have several different versions of mc with different configurations, I will just start them as XDG_CONFIG_HOME=$HOME/cfg1 mc1 and XDG_CONFIG_HOME=$HOME/cfg2 mc2. But having some files in .local/share will break this feature, because redefining XDG_DATA_HOME will break xdg-open and xdg-mime utilities started from mc bindings, since they use configurations shared by other programs in .local/share.

5. Having mc using XDG_CONFIG_HOME as a source for its configuration also allows me to easily switch a single mc version between different configurations. See p.4 why it breaks when some mc files are in .local.

Are there any benefits if some of mc files are placed .local?

[sergem]

Replying to gotar:

Again - read the former #1851 please. It has NOTHING to do with server/workstation/CLI/GUI/TUI/colour/alphabet/purpose or anything else.

Heh, the fun part is that original author of XDG Standard ​believes that you're wrong. It's just an internal specification intended ONLY for referencing by other specifications.

Waldo Bastian wrote:

XDG Base Directory spec is intended for use by other specification. For example the XDG Menu specification and Autostart specification refer to the XDG Base Directory specification instead of reinventing their own filesystem locations / hierarchy.

If there is a reason to care where applications save all or part of their data (beyond the FHS), then one could write a spec that outlines where applications should put what and one could express those locations using the XDG Base Directory spec.

XDG Standard does not say where applications should place their data because it's a base for other standards doing that. That's why it's called «XDG Base Directory Specification». If mc developers want they can write own standard, where they can say «$XDG_CONFIG_HOME/mc/ini» and that would be ​reference to the basedir specification.

There's no such thing as «XDG compliant application» among XDG standards. So actual mc standard is up to mc developers only.

[ossi]

Replying to sergem:

Replying to ossi:

for the VFS and other temp files, see the somewhat recent addition of $XDG_RUNTIME_DIR

It's not for temporary files.

says who?

It's for pid-files and sockets/pipes.

these are just examples.

Well, it depends on what you call "configuration". [...]

by your definition, any data file would be configuration. heck, even program code is configuration for the hardware.

HOME can easily be on NFS shared between architectures.

then tell me how you make a per-user, per-architecture subdirectory by easy means. don't forget allowing the user to log in simultaneously to multiple systems.

My understanding of the standard is that standard was created to put a common ground for communications between programs.

yes, and now look how kde and gnome use it. the pragmatic solution is aligning the unspecified parts with the specification. in fact, the original specification is mostly a subset of what kde was using in the first place.

1. [...] will actually increase this mess instead of reducing it.

that's utter nonsense. it's just like claiming that the introduction of a unified authentication service like openid will in fact increase the number of online identities somebody has. duh, of course it will, when there is exactly one app using it, and that only optionally.

2. [disposal]

yeah, sounds really like a case worth optimizing for.

3. [backup]

if this actually impacts your ability to backup, you have bigger problems than that.

4. [using XDG_CONFIG_HOME]

you can still do that, by symlinking into a common location. unlike splitting per config/machine, unifying is actually simple.

5. [XDG_CONFIG_HOME insufficient]

for that you have XDG_DATA_HOME. explanation above.

Are there any benefits if some of mc files are placed .local?

you mean, other than the long-term ideal of removing dotfile/dotdir clutter? if cache data was consistenly split off to separate directories throughout the system, writing backup rules would actually be easier. other than that, it seems like an exercise in pedantic futility - that's why i have no opinion about it.

[sergem]

Replying to ossi:

Replying to sergem:

It's not for temporary files.

says who?

XDG Base Directory Specification:

Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.

Replying to ossi:

It's for pid-files and sockets/pipes.

these are just examples.

These examples are what this directory was added for. IIRC Lennart Poettering asked for it, and that was the reason for a standard update. I'm not sure what he really uses it for, don't know any other specification referencing it. Do you?

by your definition, any data file would be configuration. heck, even program code is configuration for the hardware.

True. I don't know any clear definition of a config file. That's why I asked yours. And that's why I suggest to put the difference between .config and .local/share as the difference between application-specific and shared files. Why? Because it's a clear difference and it makes sense. Files shared between applications would be stored separately from application-specific files anyway. So we can use .config for application-specific files and .local/share for shared files. Why not?

then tell me how you make a per-user, per-architecture subdirectory by easy means.

I don't. What for?

1. [...] will actually increase this mess instead of reducing it.

that's utter nonsense. it's just like claiming that the introduction of a unified authentication service like openid will in fact increase the number of online identities somebody has. duh, of course it will, when there is exactly one app using it, and that only optionally.

No, it's like saying that replacing regular bugzilla registration with triple simultaneous autentification in livejournal+openid+gmail is not always the best idea, because even if a lot of people have an account in all three services there's still a lot of people who has none of them.

2. [disposal]

yeah, sounds really like a case worth optimizing for.

Well, when I want to find the software that suits me (player, calculator, im-client, pdf viewer, etc) I install the program, test it, make some notes and clean it. And it takes a lot of time, because I have to take snapshot of my home directory to find what files were changed. Just a regular user experience. :)

Or, for example, some programs stop working after upgrade because their config files format had changed, but developers had not implemented backward compatibility. Usually the easiest solution is reset to default - remove all config files of that application. And this is much easier to do when they all are in the same directory.

So, yes, having the ability to easily remove all application-specific files is a definite advantage.

3. [backup]

if this actually impacts your ability to backup, you have bigger problems than that.

Yes, making a copy of one directory is always easier than a copy of unknown number of directories and files in different places. You disagree?

4. [using XDG_CONFIG_HOME]

you can still do that, by symlinking into a common location. unlike splitting per config/machine, unifying is actually simple.

No, symlink won't allow me to run two different versions of mc with different config directories at the same time and compare them side by side. But having all files in $XDG_CONFIG_HOME/mc allows me to do that.

5. [XDG_CONFIG_HOME insufficient]

for that you have XDG_DATA_HOME. explanation above.

Not sure I understand what you mean here. Symlinks don't solve the problem, but XDG_CONFIG_HOME solve it without breaking anything. You get an advantage (a solved problem) and no disadvantages, isn't that good?

Are there any benefits if some of mc files are placed .local?

you mean, other than the long-term ideal of removing dotfile/dotdir clutter?

But putting all files in .config/mc reduces it 3 times better than putting some of them to .config, while having others in .local and .cache. Still, I named 5 reasons why it's better to use a single directory for all files. You can say those are not big advantages, but they're still advantages, right? Are there any disadvantages? Can you name some reason why placing part of files in .local/share is better then not placing any files there?

if cache data was consistenly split off to separate directories throughout the system, writing backup rules would actually be easier. other than that, it seems like an exercise in pedantic futility - that's why i have no opinion about it.

Agree. But I'm not sure that creating a cache directory for a single small rarely used file makes any sense. I mean i.e. thumbnails cache directory having thousands of files and using tens/hundreds of megabytes is somewhat different from a single .mc/Tree file that usually takes 35 bytes.

[slavazanko]

Guys, what about simple moving 'as is' ~/.mc directory to $XDG_CONFIG/HOME/mc without any of '.cache', '.local/share'? Is this applicable?

[ossi]

i don't really expect or want any "junk" in my ~/.config, so i would be moderately opposed to such a move.

[sergem]

Replying to slavazanko:

Guys, what about simple moving 'as is' ~/.mc directory to $XDG_CONFIG_HOME/mc without any of '.cache', '.local/share'? Is this applicable?

It looks like the best option for me, because:
. it attempts to reduce number of .dotfiles (what was asked about in ticket #1851)
. it puts all files in a single directory (what was asked about in this ticket #2636)
. it conforms to the XDG standard (which only defines directories, but leaves up to application what to put there)

Any other reasons I miss?

[ossi]

Replying to sergem:

. it conforms to the XDG standard (which only defines directories, but leaves up to application what to put there)

this is a completely absurd claim, and in no way it follows from what waldo said. did you even read the spec?

[ossi]

Replying to sergem:

Replying to ossi:

says who?

XDG Base Directory Specification:

hmm, right. that means that a private tempdir is still unspecified, which means that each app still needs to solve the same problem which is solved for the runtimedir.

I don't know any clear definition of a config file.

try "config files *influence* program behavior, while data files *define* it". or "config files *choose* options, while data files *provide* them". you can also try debian's definition: ​http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.1

then tell me how you make a per-user, per-architecture subdirectory by easy means.

I don't. What for?

to have different settings on different machines in a heterogeneous network.

it's just like claiming that the introduction of a unified authentication service [...]

No, it's like saying that replacing regular bugzilla registration with triple simultaneous autentification in livejournal+openid+gmail is not always the best idea, because even if a lot of people have an account in all three services there's still a lot of people who has none of them.

you know, if you make an analogy too absurd, you ridicule yourself. you just achieved that.

2. [disposal]

yeah, sounds really like a case worth optimizing for.

Well, when I want to find the software that suits me (player, calculator, im-client, pdf viewer, etc) I install the program, test it, make some notes and clean it. And it takes a lot of time, because I have to take snapshot of my home directory to find what files were changed. Just a regular user experience. :)

if you are such a homedir hygiene nazi, then put it under version control and look for unregistered files after each test. normal people wouldn't do that.

Or, for example, some programs stop working after upgrade because their config files format had changed, but developers had not implemented backward compatibility. Usually the easiest solution is reset to default - remove all config files of that application. And this is much easier to do when they all are in the same directory.

this is a fallacious argument, because you are lumping file categories together. this is exactly what i would *not* want as a problem "solution".

if this actually impacts your ability to backup, you have bigger problems than that.

Yes, making a copy of one directory is always easier than a copy of unknown number of directories and files in different places. You disagree?

you didn't do the math. if you have 20 applications with one directory each, you still have to configure the backup for 20 directories, and be selective about their content. if you have 20 applications which store their data to subdirectories of three standardized locations, you backup two of these standard locations and are done.

4. [using XDG_CONFIG_HOME]

you can still do that, by symlinking into a common location. unlike splitting per config/machine, unifying is actually simple.

No, symlink won't allow me to run two different versions of mc with different config directories at the same time and compare them side by side. But having all files in $XDG_CONFIG_HOME/mc allows me to do that.

you apparently didn't get it, because i know that it works.

I'm not sure that creating a cache directory for a single small rarely used file makes any sense.

the trick here would be not writing out the file if it's "empty" in the first place, and thus not having a practically empty cache dir.

[Perlovka]

At least panels.ini should go to the $XDG_CONFIG_HOME/mc, because it saves user defined panel layout.
This will ease backup and restore mc configuration. Also, panels layout does not changes so frequently as filepos or history file.

[slavazanko]

Okay, finally we need to do:

• new configure option --enable-homedir=<xdg | any/path/relative/to/home> (for resolve issue described in #2658). This allow users to place configs in any place such as: ~/.mc, ~/Application/bla-bla/mc or any other. In this case all files will be placed in one directory. If type of home dir will be 'xdg', then files will be placed as is now, with exceptions:
• panels.ini and mc.ext should go to the $XDG_CONFIG_HOME/mc

By default --enable-homedir=xdg

Is this right?

[ossi]

configure option is fine by me (even if i find this a bit ridiculous). the xdg default makes sense.

i'm not sure whether i have the most current state (didn't pull for a few weeks again), but looking from here:

• everything currently in .local/share belongs into .config:
  • menu
  • mc.macros (empty)
  • mcedit/edit.{spell|indent}.rc (defaults - not sure why this is even written out)
• almost everything in .cache belongs into
  • either .local/share:
    • filepos
    • history
    • mcedit/mcedit.clip
  • or .config, as you noted:
    • panels.ini
    • mc.ext (i have none, actually)

[slavazanko]

even if i find this a bit ridiculous

You right, this a bit ridiculous, but we have lot of users who have diferent the usage stories, therefore we need respect almost all users (as it's possible).

In any case, user's config dirs will be visible in

mc -F

output, so placement of these directories isn't important to us (we just ask to bugreporter to show the output of this command if needed).

[slavazanko]

Created branch 2636_configs_placement

Changesets:
25baf6da238c05e0e4fb785d489a1433fc4ea74c Ticket #2636: Move MC config files to ~/.mc instead of multiple places in $HOME
ed617ea8c2d970f56f69b9a9fd4931e8de7384c1 Changed source code for respect '--enable-homedir' configure option.
41452f75f28de7d2d34209257b76c1abf26a6c56 Some config files moved to more appropriate places.

review, please.

[slavazanko]

Merged to master: 5975ec9f66bfccc6ec7ef1afe4036a77564e69d2

git log --pretty=oneline 5cc8114...29ba0a0