Re: realpath edge cases

[Pádraig Brady]

On 24/06/17 17:02, Assaf Gordon wrote:
> Hello all,
> 
> I've encountered two interesting (?) edge-cases with realpath.
> Perhaps they warrent a change in documentation (or even 
> error-checking code).
> 
> First,
> Running 'realpath' in a deleted (unlinked) directory leads to confusing
> error messages. Example:
> 
>     # In terminal 1
>     mkdir /tmp/a
>     cd /tmp/a
> 
>     # In another terminal
>     rmdir /tmp/a
> 
>     # back in terminal 1
>     $ realpath /foo
>     /foo
> 
>     $ realpath foo
>     realpath: foo: No such file or directory
> 
>     $ realpath ../foo
>     realpath: ../foo: No such file or directory
> 
>     $ realpath -m foo
>     realpath: foo: No such file or directory
> 
> I'd say this error message is confusing, because naively 'realpath' does
> not require the last component to exist, and with '-m' it doesn't
> require any component to exist. Yet the error message hints that
> something that should exist doesn't.
> 
> The reason for the error message is this flow:
>    src/realpath.c:process_path()
>      src/realpath.c:realpath_canon()
>        gnulib/lib/canonicalize.c:canonicalize_filename_mode()
>          gnulib/lib/xgetcwd.c:xgetcwd()
> 
> Then xgetcwd fails (because the directory was deleted),
> but despite the 'x' prefix, it only dies on ENOMEM,
> not on ENOENT. It returns NULL, and the rest of the program
> fails, but errno remains at ENOENT.
> 
> Not sure what would be a good gnulib fix without breaking
> existing code that uses 'canonicalize_filename_mode'.
> 
> Of course, it is always recommended not to run programs
> in a deleted directory... many programs will fail with confusing
> errors.

Yes, it would be better to improve the error for this case
to say we can't get the name of the _current directory_.

> Second,
> `realpath --help` shows:
>   --relative-to=FILE       print the resolved path relative to FILE
>   --relative-base=FILE     print absolute paths unless paths below FILE
> 
> This hints (to a naive person like me :) ) that realpath will calculate
> relative path to any file. But in fact, it assumes that the FILE
> argument is always a directory, and with 'realpath -e' it indeeds
> verifies it's a directory.

> So perhaps just update the usage text? (patch attached).
> If not, then add a new 'gotcha' ?

> --- a/src/realpath.c
> +++ b/src/realpath.c
> @@ -81,8 +81,8 @@ all but the last component must exist\n\

> -      --relative-to=FILE       print the resolved path relative to FILE\n\
> -      --relative-base=FILE     print absolute paths unless paths below 
> FILE\n\
> +      --relative-to=DIR        print the resolved path relative to DIR\n\
> +      --relative-base=DIR      print absolute paths unless paths below DIR\n\

Yes this is clearer.
Otherwise one might also think the FILE's directory is used.
Please update the info doc also.

thanks!
Pádraig