So this is an open question... Is this backportable as a bug fix? Both are errors as the reference to a specific file, but only one condition represents a fatal error for a grep operation.
Should we wait for 1.8 or is this worth 'adjusting' in 1.7.1 asap? I already have conflicting thoughts so wanted to raise it as a question. On Thu, Jan 16, 2020, 13:20 <wr...@apache.org> wrote: > Author: wrowe > Date: Thu Jan 16 19:20:29 2020 > New Revision: 1872893 > > URL: http://svn.apache.org/viewvc?rev=1872893&view=rev > Log: > Be more forceful in identifying EBADPATH > > Even when the path is first identified as a wildcard path. > > Modified: > apr/apr/trunk/file_io/win32/filestat.c > > Modified: apr/apr/trunk/file_io/win32/filestat.c > URL: > http://svn.apache.org/viewvc/apr/apr/trunk/file_io/win32/filestat.c?rev=1872893&r1=1872892&r2=1872893&view=diff > > ============================================================================== > --- apr/apr/trunk/file_io/win32/filestat.c (original) > +++ apr/apr/trunk/file_io/win32/filestat.c Thu Jan 16 19:20:29 2020 > @@ -32,6 +32,8 @@ > */ > static apr_status_t test_safe_name(const char *name) > { > + apr_status_t rv = APR_SUCCESS; > + > /* Only accept ':' in the second position of the filename, > * as the drive letter delimiter: > */ > @@ -41,13 +43,13 @@ static apr_status_t test_safe_name(const > while (*name) { > if (!IS_FNCHAR(*name) && (*name != '\\') && (*name != '/')) { > if (*name == '?' || *name == '*') > - return APR_EPATHWILD; > + rv = APR_EPATHWILD; > else > return APR_EBADPATH; > } > ++name; > } > - return APR_SUCCESS; > + return rv; > } > > static apr_status_t free_localheap(void *heap) { > > >
