[PATCH 11/11] Ensure temporary directory used by tests exists

[Brian Inglis]

On 2020-11-08 12:27, Ken Brown via Cygwin-patches wrote:
> On 11/8/2020 1:52 PM, Jon Turney wrote:
>> On 08/11/2020 18:19, Ken Brown via Cygwin-patches wrote:
>>> On 11/5/2020 2:47 PM, Jon Turney wrote:
>>>> +# temporary directory to be used for files created by tests (as an absolute,
>>>> +# /cygdrive path, so it can be understood by the test DLL, which will have
>>>> +# different mount table)
>>>> +tmpdir = $(shell cygpath -ma $(objdir)/testsuite/tmp/ | sed -e
>>>> 's#^\([A-Z]\):#/cygdrive/\L\1#')
>>>
>>> This isn't right if the cygdrive prefix is not 'cygdrive'.  Maybe use
>>> 'proc/cygdrive' instead of 'cygdrive'?

>> That's how I originally had it.  Unfortunately, test ltp/symlink01 relies on
>> the test directory being specified as a canonicalized pathname (i.e. is the
>> same after realpath()).
>>
>> Since there's no /etc/fstab in the the filesystem relative to the test DLL, I
>> think it should always be using the default cygdrive prefix?
> 
> But there's a mkdir command that seems to be run in the context of the user
> running 'make check'.  If the cygdrive prefix is not 'cygdrive', 'make check'
> fails as follows:
> 
> ERROR: tcl error sourcing
> /home/kbrown/src/cygdll/newlib-cygwin/winsup/testsuite/winsup.api/winsup.exp.
> ERROR: can't create directory "/cygdrive": permission denied
>     while executing
> "file mkdir $tmpdir/$base"

Unfortunately, cygpath has limitations dealing with paths with trailing
component symlinks, and readlink has limitations dealing with paths with leading
symlinks, while realpath overcomes those limitations and has other options to
deal with symlink issues:

$ cygpath ~/RPi
/home/bwi/RPi
$ readlink ~/RPi
Documents/Info/RPi
$ realpath ~/RPi
/.../Documents/Info/RPi

Could you not use:
tmpdir = $(shell realpath $(cygpath -aU $(objdir)/testsuite/tmp/))
or:
tmpdir = $(shell cygpath -aU $(objdir)/testsuite/tmp/ | xargs realpath)
otherwise:
	pfx=$(realpath /proc/cygdrive)
to get the drive prefix and use that directly when appropriate?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]