Multiple base directory details

[Bollinger, John C]

Dear XDG folks,

I'm working on an implementation of the XDG Base Directory specification, and I ran into several issues on which I would like clarification or guidance.  I hope you can help.

----

1. Colons in file names

Colons (:) appearing in the values of $XDG_DATA_DIRS and $XDG_CONFIG_DIRS or their specified default values serve as path separators.  Colons are also valid filename characters on many systems toward which the specification is targeted, but no mechanism is specified for escaping colons, so it follows that path segments containing colons cannot be represented in the values of these variables (please confirm).

On the other hand, the four user-directory variables are each specified to name a _single_ base directory, so colons appearing there should be recognized as normal filename characters (please confirm).

Such inconsistent treatment is not a major problem in itself, but it does mean that it is not safe to form combined paths from the values of these variables, such as $XDG_CONFIG_HOME:$XDG_CONFIG_DIRS, which one might otherwise be inclined to do in conjunction with trying to locate a file to open for reading.

----

2. Trailing slash characters in paths

The specification is inconsistent with respect to the form in which it presents default base directory paths.  Most are specified without trailing slashes, but the default for $XDG_DATA_DIRS is presented with them.  Taking the specification to be correct, it seems likely that the intent is for such trailing slashes to be insignificant (please confirm), not only in the default values but also in user-specified values (please confirm).  In that case, does the same apply to _multiple_ trailing slashes?

----

3. Relative base directories

The intent of the specification seems to be that base directories will be expressed as absolute paths, but that is not an explicit constraint (so please confirm), and there is no discussion of how relative paths given as base directories ought to be treated.  A naïve implementation might interpret such paths relative to the current working directory, with surprising and perhaps dangerous results.  If relative paths are to be allowed, then it makes more sense to interpret them relative to $HOME, provided, of course, that that variable specifies an absolute path itself.  Is this to be preferred over rejecting relative paths as erroneous?  If relative paths are to be rejected, then is there any guidance on whether or when an error message should be emitted?

----

4. Default for $XDG_RUNTIME_DIR

It is understandable that the specification does not designate a default value for $XDG_RUNTIME_DIR, as system configurations are too varied to allow it to name one that will have all the desired properties on every system.  For the same reason, however, it is unreasonable to expect individual applications to make such a choice, either, and if one nevertheless did have that expectation then one should also expect that different applications would choose inconsistently, thus defeating the purpose.

I see two alternatives: (a) it is considered erroneous for $XDG_RUNTIME_DIR to fail to designate a usable directory in the event that an application wants to write runtime files; or (b) some mechanism is defined, such as a standard configuration file, by which system administrators can set an appropriate default on a per-system basis.  I would be inclined to suggest (a), as the case where $XDG_RUNTIME_DIR is empty or unset is not necessarily distinct from the one in which $XDG_RUNTIME_DIR is set to a value that ends up not being usable, and because there already are standard mechanisms by which sysadmins can cause $XDG_RUNTIME_DIR to be set to an appropriate value by default.

----

5. What constitutes writing to a file?

The specification says that "If, when attempting to write to a file, the destination directory is non-existant [sic] an attempt should be made to create it", but that's a bit inconsistent with how things actually (can) work.  Files must be opened before they are written to, at least implicitly, and it is at that point that the choice must be made about whether to create any directories, regardless of whether any attempt is ever made to actually write data.  Even shell scripts can open files without writing to them.

There are several variations on how that could be interpreted, but the one that makes the most sense to me is that an attempt to create parent directories should be made before or as part of opening a file in a mode and manner that permits writing and requests creation of the file if it is absent, but not in other cases.  In terms of the open(2) function, that means when the flags contain O_CREAT and one of O_WRONLY or O_RDWR.  Is this in fact the intent?  If not, then what?

Note: do consider the case of O_CREAT | O_RDONLY when the target file does not already exist - does creating a read-only file constitute "writing to a file" for the purposes of the specification?  According to my suggested interpretation, no, it does not.

----

Sorry for the long-windedness.


Thanks,

John

--
John Bollinger
John.Bollinger AT StJude DOT org

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20190620/eee30c12/attachment.html>