config.md: fix ambiguous words

[Mashimiao]

Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com

[dqminh]

path must be an absolute path sounds a bit strange for me. I would be curious on why do you think the original phrase was confusing.

[Mashimiao]

First, I think absolute path is one kind one set phrase. Just say a path is absolute seems not suitable, because absolute has several meanings, we can't express ourself very clearly.
Second, we can see many other places in spec use absolute path.

[wking]

On Wed, Jul 05, 2017 at 03:20:29AM -0700, Ma Shimiao wrote: First, I think `absolute path` is one kind one set phrase. Just say a path is absolute seems not suitable, because `absolute` has several meanings, we can't express ourself very clearly. Second, we can see many other places in spec use `absolute path`.

We also use “absolute” by itself for mounts[].source [1]. If we want to be formal about it, we can use “absolute pathname” [2,3], although POSIX does occasionally use “absolute path” [4,5], “absolute root directory” [6], “making a relative pathname into an absolute one” [6], etc. I'm fine however we want to do this, but it would be good to be consistent. And I'd be happiest if we somewhere defined absolute path(names), either by linking to [2] where we use it or by adding our own local definition to our glossary, but there has been resistence to that in the past [7]. [1]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L77 [2]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_02 [3]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 [4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html#tag_16_487_05 See the EBADF and ENOTDIR entries. [5]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/readlink.html#tag_16_476_05 See the EBADF and ENOTDIR entries. [6]: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_06 [7]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-05-31-21.02.log.html#l-96

[Mashimiao]

I don't think we need to add local definition. It almost a common view, we can assume readers know what absolute path or relative path is. Does POSIX add its own local definition?

[hqhq]

The original phrase looks pretty clear to me.

[Mashimiao]

That's not only problem about looks clear or not but also consistent in document

[wking]

On Tue, Jul 11, 2017 at 02:56:44AM +0000, Ma Shimiao wrote: Does POSIX add its own local definition?

Yup, see [1], which I'd also cited from [2]. Note that, per POSIX, //foo is not absolute (although both /foo and ///foo are absolute) [1] and it is also not relative [3]. Instead, //foo is implementation-defined [4], and as far as I can tell, pathnames beginning with two slashes have no convenient name in POSIX. Boost respects this and has a test showing // as not absolute [5] (although strangely they use !is_absolute for is_relative [6] which does not match POSIX). In Linux, on the other hand, *all* paths starting with a slash are absolute [7,8]. Go uses the Linux logic [9] as does Python [10]. Without a punt to *someone* or a local definition, it's not clear to me whether runtimes should consider //foo absolute (like Linux, Go, Python, etc.) or implementation-defined (like POSIX, Boost, etc.). [1]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_02 [2]: #879 (comment) [3]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_324 [4]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 [5]: https://github.com/boostorg/filesystem/blob/boost-1.64.0/test/path_test.cpp#L861 [6]: https://github.com/boostorg/filesystem/blob/boost-1.64.0/include/boost/filesystem/path.hpp#L527-L532 [7]: http://man7.org/linux/man-pages/man7/path_resolution.7.html [8]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/path-lookup.md?h=v4.12#n41 [9]: https://go.googlesource.com/go/+/go1.8.3/src/path/path.go#199 [10]: https://github.com/python/cpython/blob/v3.6.1/Lib/posixpath.py#L64-L66

[tianon]

Given that we're discussing Linux containers, I think we are already assumed to be using the Linux definition, which matches Go, Python, etc. If Solaris has a different idea for what "absolute" means (which I'm not convinced it does), that's fine, and still unambiguous IMO. We're relying on the platform-specific definition of the term "absolute path", and every platform we support has _some_ well agreed-upon definition of that (for example, as you described, in Linux, "/foo", "//foo", and "///foo" are all absolute, but "./foo", ".//foo", ".///foo", "foo" are not). I really do not see any value in our specification explicitly defining what "absolute path" means.

[tianon]

This seems redundant. In the current wording, "absolute" and "relative" are adjectives describing the "Path values", and usage like "X path is absolute" or "X path is relative" are pretty common.

[Mashimiao]

OK, closing it.

[wking]

On Thu, Jul 13, 2017 at 10:55:35PM +0000, Tianon Gravi wrote: Given that we're discussing Linux containers…

Are we only discussing Linux containers? mounts[].source, for example, does not have a platform-specific guard as far as I can see [1].

If Solaris has a different idea for what "absolute" means (which I'm not convinced it does)…

Yeah, I don't know how Solaris interprets double-slash paths.

We're relying on the platform-specific definition of the term "absolute path", and every platform we support has _some_ well agreed-upon definition of that (for example, as you described, in Linux, "/foo", "//foo", and "///foo" are all absolute, but "./foo", ".//foo", ".///foo", "foo" are not).

So if someone decided to use Boost to determine absolute-ness, and therefore characterized //foo as not-absolute (which is how Boost works on Linux), you'd consider that a Boost bug, and not a spec-ambiguity bug? [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc6/config.md#mounts

[tianon]

Yes, because the rest of Linux disagrees with Boost's definition.

[epilatow]

The solaris kernel path parser maps path components like '//' and '/./' to '/'. An absolute path on solaris is one that begins with '/'. Imo code that treats things like '//' and '/./' as invalid path components is being overly pedantic and user-unfriendly.

[wking]

On Fri, Jul 14, 2017 at 10:54:11AM -0700, Edward Pilatowicz wrote: The solaris kernel path parser maps path components like '//' and '/./' to '/'. An absolute path on solaris is one that begins with '/'.

Ok, so the // that POSIX leaves implementation-defined is handled the same way on both Linux and Solaris. Windows seems to have reasonably clear docs on absolute vs. relative as well [1], although it's not clear to me where volume GUID paths [2] (which we use for root.path [3]) fit in that categorization. Are they legal mounts[].source values? Maybe they're excluded as “UNC paths and mapped drives” [4]? [1]: https://technet.microsoft.com/en-us/library/ee692607.aspx [2]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365248%28v=vs.85%29.aspx [3]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L37 [4]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L78