Pádraig Brady <[email protected]> writes:
>> Also, I think it would be difficult to add a test case since many
>> systems do not support directories that deep.
>
> ...we do actually have a test for this in tests/pwd/pwd-long.sh
> However it doesn't trigger because the getcwd syscall
> handles the long path and thus bypasses this fallback code in pwd.c
>
> Note we didn't notice a test failure on any of the many systems we test on
> (I re-reviewed all of Bruno's recent test runs for coreutils 9.10 for e.g.)
> which suggests this fallback code is not run on any modern system.
> I tweaked pwd.c on Solaris 11, FreeBSD, and Linux to not call the system
> getcwd()
> and the test failed on each with the fallback code without the fix.
Yes, I'm aware of that test. But I did not think it was long enough make
getcwd fail. Usually I do something like this:
$ mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
$ while cd $(yes a/ | head -n 1024 | tr -d '\n'); do :; done 2>/dev/null
I couldn't reproduce the issue with those invocations. I assume this is
probably because xpalloc will allocate a larger amount of memory than
requested to avoid repeated allocations.
> I've attached an adjustment to the test to use strace to
> avoid the getcwd syscall, which is enough on Linux at least to
> trigger our fallback code to run. With that the test fails
> without Chris's patch, and passes with it.
Likewise, I see the same behavior. I think that is good to push. Thanks
for the test case.
Collin
