At 10:42 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Obviously, the type at least did not make it into the fle info. Looking
>at this code again, the patch may indeed be wrong; but I find it really,
>really hard to follow that code. In fact, I can't understand it at all.
>If you can enlighten me about what's happening there, I may be able to
>come up with a better patch.
What I would like to know (if you can track it...)
Is it possible to dump the finfo structure within gdb at the point this
request fails? I'd pay especially close attention to the .valid bits, since
those are the identifiers that will help us determine if stat() was also
called later.
First; the definition of all the apr_file_info...() fn's is to return *ALL* of the
available information. If more information is available (without extra
effort) than the user requests, that is always OK.
If some 'extra step' must be performed on a given platfrom (e.g. win32 can't
just get an inode/dev without drilling with an open file handle), then we
*must* perform that extra step.
I'm very interested in what is returned in .filetype. The definition of d_type
is to spell out what info is available about the file directory entry. This is
an lstat() style info (that is, the file doesn't reside in a directory, the
link to the file does.)
>I reverted my change, but be aware that apr_dir_read is currently
>broken. It simply does not work on Linux with a redent glibc, it also
>doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed.
Thanks... If you can spell out how we called apr_dir_read it might help
me a ton. I'm actively interested in helping debug the issue with the
right fix.
A.F.A rbb's complaint; if this code is difficult to read, by all means we
should refactor for clarity.
However, there is no reason *not* to deal with ALL of the information
we can recover from struct dirent, if it proves reliable. I strongly suspect
we are looking for some unrelated datum that we 1) didn't request, or
2) recovered an APR_INCOMPLETE because some bit was requested
that can't be recovered on the platform in question. Or 3) there is some
very obvious, fat fingered mistake of mine in the code.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 18 06:22:22 2002