Hi Pierre,
On Wed, Jun 2, 2010 at 11:42 PM, Pierre Habouzit <madcoder@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
