Re: [Bug libc/11459] New: ftw doesn't work like documented (may be a documentation bug)

[Michael Kerrisk <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

Hi Pierre,

On Wed, Jun 2, 2010 at 11:42 PM, Pierre Habouzit <madcoder-zi3NMfd+bKEdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, May 24, 2010 at 07:41:49PM +0200, Michael Kerrisk wrote:
>> Hello Pierre,
>>
>> On Tue, Apr 6, 2010 at 11:03 AM, Pierre Habouzit <madcoder-zi3NMfd+bKFQFI55V6+gNQ@public.gmane.orgg> wrote:
>> > See below a bug reported against the glibc.  Since the glibc maintainer
>> > dodged that one, I assume the bug indeed is in the documentation of
>> > ftw(3). My manpages are the 3.24-1 Debian package.
>>
>> Yes. The man page is clearly incorrect. Thanks for reporting this.
>>
>> > IMHO the patch is:
>> >
>> >  -fpath is the pathname of the entry relative to dirpath.
>> >  +fpath is the pathname of the entry relative to the current working directory.
>> >
>> > POSIX is very vague about what "fpath" should be btw.
>>
>> (Agreed. It could be more precise.)
>>
>> I believe the correct text should be this:
>>
>>        fpath   is  the  pathname  of  the  entry,  and  is
>>        expressed either as  a  pathname  relative  to  the
>>        calling  process's current working directory at the
>>        time of the call to ftw(), if dirpath was expressed
>>        as a relative pathname, or as an absolute pathname,
>>        if dirpath was expressed as an  absolute  pathname.
>>
>> I have updated the man page accordingly, but would welcome
>> review/checking of this text.
>
> Afaict, it's not correct: ftw may perform chdir() calls, so the pathname
> is relative to the current working directory at the time `fn` is called.
>
> I'd rather phrase it that way (minus probable english mistakes):
>
>    fpath is the pathname of the entry, and is either a relative
>    pathname to the current working directory of the application when
>    `fn` is called, or as an absolute pathname.

Thanks for taking a look at this. However, I *think* your analysis is
wrong, and my proposed changes is right. But, still I'd like some
further confirmation. Please take a look at the the program below, and
the output produced when it runs.

$ cat t.c
#include <stdio.h>
#include <stdlib.h>
#include <ftw.h>

/* Function called by ftw(): print type, i-node number, size in
   bytes, and name of each file. */

static int
displayFileInfo(const char *pathname, const struct stat *sbuf, int type)
{
    printf("%c ", (type == FTW_D) ? 'd' : (type == FTW_DNR) ? 'D' :
                  (type == FTW_F) ? 'f' : (type == FTW_SL) ? 's' :
                  (type == FTW_NS) ? 'N' : '?');
    if (type != FTW_NS)
        printf("%7ld %7lld ", (long) sbuf->st_ino,
                (long long) sbuf->st_size);
    else
        printf("                ");
    printf("%s\n", pathname);

    /* Let's mess with the curent directory during the ftw() call,
       to see what value is passed to 'pathname' in successive calls
       to displayFileInfo() */

    chdir("..");
    system("pwd");

    return 0;           /* to tell ftw() to continue */
}

int
main(int argc, char *argv[])
{
    if (ftw((argc < 2) ? "." : argv[1], displayFileInfo, 10) == -1) {
        perror("ftw");
        exit(EXIT_FAILURE);
    } /* if */

    exit(EXIT_SUCCESS);
}
$ cd dir1
$ find ../dir2
../dir2
../dir2/sub
../dir2/sub/b
../dir2/sub/a
../dir2/bbb
$ ../a.out ../dir2/
d 9863613    4096 ../dir2
/home/mtk/tlpi/dirs_links
d 1236107    4096 ../dir2/sub
/home/mtk/tlpi
f 9176008       0 ../dir2/sub/b
/home/mtk
f 9176007       0 ../dir2/sub/a
/home
f 7635615      38 ../dir2/bbb
/

See how the CWD changes, but the pathname is always expressed with
respect to "dir1"? Do you agree with my text now, or do you still see
some problem?

Thanks,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html