Subject: bug#36416: realpath doesn't preserve '..' consistently as per POSIX, nor '/.'

From: Eric Blake <[email-masked]>
Date: Fri, 28 Jun 2019 14:02:39 -0500

On 6/28/19 12:47 PM, L A Walsh wrote:
> I don't recall reading anything about posix allowing the elimination
> of such paths.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html

4.13:
"If a pathname begins with two successive <slash> characters, the first
component following the leading <slash> characters may be interpreted in
an implementation-defined manner, "

Linux has an implementation-defined manner: "// is an alias for /, and
therefore may be shortened"

Cygwin has an implementation-defined manner: "// is distinct from /, and
therefore must be preserved"

Note that "may be shortened" is not synonymous with "must be shortened"
nor with "must be preserved".  So on Linux, preserving "//" is
POSIX-compliant, AND shortening "//" to "/" is POSIX-compliant (since
both choices comply with the implementation definition).

> 
> If I have an application layer on top of linux that processes those
> double slashes, it may or may not work depending on the underlying OS?

If your application layer is on top of Linux, then yes, the underlying
OS guarantees that your application processing a path beginning with
"//" is correct whether it preserves or shortens that path to "/".

If you port the source code of an application originally built on Linux
to then operate on some other operating system, then the source code is
buggy if it shortens the path to "/". But you have to actually check the
source code to see if it has that bug - just because 'realpath' in
coreutils shortens '//' to '/' on Linux does NOT mean that it is buggy,
because the code for realpath has an explicit check (run at
configure-time) for whether "//" is distinct from "/" - and on platforms
where that check is answered differently than on Linux, the code behaves
differently.  That is, the coreutils code is self-adapting to the
implementation definition of the implementation it is compiled on.

> It would useful if bugs were not closed before asking for more
> information. 

They can always be reopened if you provide enough relevant information
to show it was closed prematurely.  But so far in this case, you have
not done so, but merely confirmed my suspicions - you noticed a
difference in behavior between Linux and Cygwin, but both behaviors were
POSIX-compliant when factoring in the implementation-defined nature of
the underlying implementation.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org