"crontab -e" backup file creation causes error if ~/.cache does not exist

[hannob]

When using crontab -e and changing the crontab, I get this error:

/home/[username]/.cache/crontab: mkdir: No such file or directory

It seems recent cronie versions have introduced a feature to create backup files that are saved in ~/.cache/crontab. But it does not check that the ~/.cache directory exists.

[t8m]

I do not think I should create the .cache dir if it does not exist.

This message is just a warning and a backup won't be created but otherwise things should work.

There are basically three options:

1. Silence the message if .cache is not present
2. Make the message more comprehensive such as "No .cache directory in $HOME, backups won't be created."
3. Create the crontab directory directly in home (probably with a different name such as .crontab-backups instead).

Which one is preferable?

[t8m]

My preference is either 2 or 3.

[hannob]

Creating ".cache" when it does not exist is what applications usually do, and what the spec says ("If, when attempting to write a file, the destination directory is non-existant an attempt should be made to create it with permission 0700. " https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.8.html ). Though I am wondering a bit if .cache is the correct place for a backup file anyway.

[hartwork]

Though I am wondering a bit if .cache is the correct place for a backup file anyway.

Maybe XDG_DATA_HOME (default ${HOME}/.local/share) rather than XDG_CACHE_HOME.

PS: /var/lib/<editor> in FHS 3.0 seems related content-wise (but /var is probably no option here due to permissions).

[t8m]

I'd prefer keeping it at .cache / XDG_CACHE_HOME.

IMO an old backup file is something that does not have to be persistent. It is more like Oh I realized I made a mistake, can I revert?

[hartwork]

@t8m I would like to highlight that a cache is substituting runtime by storage and it holds content that can be re-computed without loss at any time if deleted. If the content of a cache does not fit that model, it's probably not a cache. A backup is very different from that in that it holds content that has no guarantee that it can be recomputed in fact its mere cause of existence is to protect against that very cause. So in some sense a cache directory could hardly be further from a semantic match to storing backup files, or am I'm missing something?

[t8m]

That is one definition of cache which is a very strict one. In my opinion these backups are not meant to be permanent and I do not think there is a better place for such kind of "temporarily useful files" than .cache.

[hartwork]

That is one definition of cache which is a very strict one.

@t8m what would be your definition of cache?

In my opinion these backups are not meant to be permanent

How is permanent or not important to this discussion? Please help me see it.

and I do not think there is a better place for such kind of "temporarily useful files" than .cache.

Why would XDG_DATA_HOME not be a fit or worse than XDG_CACHE_HOME for (temporary or not) backup files? I don't see why a cache folder would even be on the list of candidates for backup files. I already explained in detail why at https://github.com/cronie-crond/cronie/issues/173#issuecomment-1906973100 .

[t8m]

XDG_DATA_HOME is for permanent storage so it is definitely not the place I would like to use.

From the specs linked above: $XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. That sounds like a good fit for temporary backup files.

[anthonyryan1]

Bumping this issue, because we got lost in the bikeshedding.

Whatever the debate over the most semantically correct directory, that's separate to the fact that cronie is failing to work because it's not following the spec and creating the directory when it does not exist.

I feel like we should create ~/.config when missing (matching the spec).

Even if we change the directory later, the need to create the directory where it doesn't exist will persist. So that much can probably be agreed upon.