paths[with spaces and square brackets] cannot be listed in %files

[hroncok]

Consider this spec file:

Name:           reproducer
Version:        0
Release:        0
Summary:        ...
License:        MIT
BuildArch:      noarch

%description
...

%prep

%install
touch '%{buildroot}/file[with spaces]'

%files
"/file[with spaces]"

RPM 4.16 and 4.17 will fail to build it with:

Processing files: reproducer-0-0.noarch
error: File not found: .../rpmbuild/BUILDROOT/reproducer-0-0.x86_64/file[with
error: Path is outside buildroot: spaces]

It seems that even thou the path is in " quotes, the spaces split it into multiple paths.

[pmatilai]

Looks like a bug someplace.

Wildcards usually get you around obstacles where other escaping methods fail:
/file?with?spaces? works, except of course if you have multiple similarly named files, some using [ ] and others { } etc...

[dmnks]

Seems to be caused by __glob_pattern_p() where a filename containing square brackets is interpreted as a glob (which then messes up our glob parsing logic later in the process, resulting in the filename being split into two at the space char). Will take a closer look.

[hroncok]

The semantics of escaping stuff in %files is not very clear. See also this thread: http://lists.rpm.org/pipermail/rpm-list/2021-June/002048.html

[dmnks]

Yeah, documentation also seems to be lacking here. Thanks for the report!

[hroncok]

Seems to be caused by __glob_pattern_p() where a filename containing square brackets is interpreted as a glob (which then messes up our glob parsing logic later in the process, resulting in the filename being split into two at the space char). Will take a closer look.

Including { and } behaves similarly.
It would be really useful if we could escape the glob characters somehow.

[gotmax23]

Seems to be caused by __glob_pattern_p() where a filename containing square brackets is interpreted as a glob (which then messes up our glob parsing logic later in the process, resulting in the filename being split into two at the space char). Will take a closer look.

Including { and } behaves similarly. It would be really useful if we could escape the glob characters somehow.

Here1 is the full RHBZ ticket for the issue that Miro's referring to.

[dmnks]

As far as semantics, what we should aim for, I think, is that it's similar to a typical shell (like Bash): the entries in a %files section are pathnames to be matched against the buildroot tree and are subject to expansion using the conventional glob characters. Similarly to a shell, it should be possible to escape these characters.

As far as the current implementation, the glob chars are supported, but the backslash escape char only works partially; it avoids the expansion of the pathname in processBinaryFile(), but it is then passed to the low-level system functions like lstat(2) (via addFile()) unchanged, i.e. with the escape chars still in place, which obviously fails to match the desired filename. In addition, the backslash doesn't work with spaces; there's a check that runs before pathname expansion that checks whether the given pathname is absolute; this check doesn't understand escaping, though, so it errors out, as seen in the original comment above.

As an alternative to the backslash, pathnames can be enclosed in quotes. These do work for space chars, however, for a change, they do not work for glob chars.

As an example, for the following pathnames in %files, rpmbuild behaves as expected, similarly to a shell:

• /foo[bar] is expanded and if it doesn't yield any matches, it's matched verbatim
• /foo bar is interpreted as two paths
• "/foo bar" is matched verbatim

However, the following works unlike a shell and thus is arguably incorrect (or at least unconventional):

• "/foo[bar]" is expanded
• /foo\ bar is interpreted as two paths
• /foo\[bar\] is matched verbatim (i.e. with literal backslashes), whereas the expected semantics here would be "this is not a glob, treat it as a literal /foo[bar]")

Therefore, a combination of glob and space chars can't be properly escaped; neither backslashes nor quotes will do the trick here:

• "/foo[bar baz]" is expanded
• /foo\[bar\ baz\] is interpreted as two paths
• "/foo\[bar baz\]" is matched verbatim (i.e. with literal backslashes)

In other words, the root cause is threefold (same order as above):

• Quotes don't escape globs (just spaces)
• Backslashes don't escape spaces (just globs)
• Backslashes are not stripped after determining whether the pathname is a glob

Either the first or the last one, if addressed, would resolve this issue. The second one is orthogonal to this particular problem, but would also be nice to have eventually.

Next, I'm going to look closer at the code and the logic around this to see if implementing some of the suggested fixes would be safe and not cause some breakage elsewhere.

[hroncok]

That is a very good analysis of the problem, @dmnks. Thank you!

[ffesti]

Is this issue related to #1294 ?

[dmnks]

Possibly, even though there it seems that quoting doesn't work with %doc entries (whereas it does for plain entries). I'll have a look at it later.

[dmnks]

I'm reopening this issue as there's still outstanding work to be done in terms of making the quotes behave as expected (i.e. escaping the enclosed content), which I have almost ready. I'll open another PR soon.

[kloczek]

Quite possible that this PR broke shell globs in %files
#2649