+++ This bug was initially created as a clone of Bug #1634659 +++

As the upstream bug on find POSIX definition has been resolved
http://austingroupbugs.net/view.php?id=1133
And the definition of -mount has been therefore changed

As also reported in upstream (GNU bug)
https://savannah.gnu.org/bugs/?54745

My customer would like to have the related downstream bug opened.

Short note over the modification need:
"""
When restricting the search to files on one file system, it can sometimes be desirable for the crossing points themselves to be acted on and sometimes for them not to be acted on. (Crossing points are mount points and, if the -L option is specified, symbolic links to directories on other file systems.) The -xdev primary acts on them and the -mount primary does not. However, -mount also does not act on symbolic links to non-directory files on other file systems (if -L is specified). If there is a need for an application to exclude crossing points but include symbolic links to non-directory files on other file systems, this can be achieved by using two find commands as follows:
find -L dir -mount -type d -print
find -L dir -xdev ! -type d -print
(in a subshell whose output is piped to sort, if the order matters).
If both -mount and -xdev are specified, find obeys both primaries but the end result is the same as if -xdev were not specified.
"""

— Additional comment from Red Hat Bugzilla Rules Engine on 2018-10-01 05:52:31 EDT —

Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.

— Additional comment from Kamil Dudka on 2018-10-01 08:14:35 EDT —

I do not think we can change the current behavior in a minor update of RHEL-7.

— Additional comment from Daniele on 2018-11-07 04:35:57 EST —

(In reply to Kamil Dudka from comment #2)
> I do not think we can change the current behavior in a minor update of
> RHEL-7.

Considering for RHEL8 is also ok, I guess, but even for that the time is shrinking so we'd need a shorter reaction time. If we "miss" RHEL8, that closes the possibility to change this for a very long time.

— Additional comment from Kamil Dudka on 2018-11-19 08:19:54 EST —

— Additional comment from Kamil Dudka on 2018-11-19 08:21:36 EST —

Given the fact that we are not able to implement this in a backward compatible way, are you fine with moving this request to RHEL-8?