[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tw() not correctly handling symlinks

From: Michael Kerrisk
Subject: Re: tw() not correctly handling symlinks
Date: Sat, 28 Jul 2001 13:09:48 +0200

Hello Ulrich,

I've embedded results of my tests below on OSF/1 5.1a and SunOS 5.7 for 
the ftw() question I raised with you a while back.  OSF/1 ftw() does not 
follow symlinks, while SunOS does.  As I said before, the key question is: 

In what circumstances (if any) will/should glibc:ftw() pass FTW_SL as a 
value to flag?  

What is your take on that?  (Bearing in mind the Austin does allow for 
ftw() to passs FTW_SL)

I have also included a slightly modified version of my earlier program 
which uses system() to create the required symlinks for test purposes




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

displayFileInfo(const char * path, const struct stat *sbuf, int type) {
    printf("%c %7ld   %s\n",
        (type == FTW_D || type == FTW_DNR) ? 'd' :
        (type == FTW_F) ? 'f' :
        (type == FTW_NS) ? 'n' :
        (type == FTW_SL) ? 's' : '?',
                sbuf->st_size, path);
    return(0);  /* to tell ftw that we had no errors... */
} /* displayFileInfo */

main(int argc, char *argv[])
    system("touch a; ln -s a b; ln -s c d; ls -l");
    ftw((argc < 2) ? "." : argv[1], &displayFileInfo, 10);
} /* main */


$ uname -a
OSF1 spe152.testdrive.compaq.com T5.1 1278 alpha
$ cc test_ftw.c
$ ./a.out
total 21
-rw-r--r--   1 mtk16    nis            0 Jul 27 06:00 a
-rwxr-xr-x   1 mtk16    nis        20128 Jul 27 06:01 a.out
lrwxrwxrwx   1 mtk16    nis            1 Jul 27 06:01 b -> a
lrwxrwxrwx   1 mtk16    nis            1 Jul 27 06:01 d -> c
-rw-r--r--   1 mtk16    nis          621 Jul 27 06:00 test_ftw.c
d    8192   .
f       0   ./a
s       1   ./b
f   20128   ./a.out
f     621   ./test_ftw.c
s       1   ./d


573:f> uname -a
SunOS polyphem 5.7 Generic_106541-12 sun4u sparc SUNW,UltraSPARC-IIi-Engine 
575:f> gcc test_ftw.c 
576:f> ./a.out 
total 20 
-rw-r--r--   1 mtk      users          0 Jul 27 11:50 a 
-rwxr-xr-x   1 mtk      users       7132 Jul 27 11:50 a.out 
lrwxrwxrwx   1 mtk      users          1 Jul 27 11:50 b -> a 
lrwxrwxrwx   1 mtk      users          1 Jul 27 11:50 d -> c
-rw-r--r--   1 mtk      users        622 Jul 27 11:48 test_ftw.c 
d     512   . 
f       0   ./a 
f    7132   ./a.out 
f     622   ./test_ftw.c 
f       0   ./b 
n       1   ./d

------- Forwarded message follows -------
From:                   Michael Kerrisk <address@hidden>
To:                     address@hidden
Subject:                Re: (Fwd) ftw() not correctly handling symlinks
Copies to:              address@hidden
Date sent:              Thu, 12 Jul 2001 10:33:56 +0200

> As for your report: you completely misunderstand the difference
> between ftw() and nftw().  Especially why there is nftw() in the first
> place.

I've been reading the standards pretty closely, though as I mentioned, it
seems to me that XSH:ftw() is not completely clear on this point (i.e.
whether or not ftw() should follow symlinks - the implication of a XBD 4.11
is that unless otherwise stated, it should, however the presence of the
FTW_SL flag for ftw() implies otherwise).  

I tested the sample program I already sent you on OSF/1-5.1a - it gives the
reults I expected - i.e. symbolic links are NOT followed, and ftw() passes
FTW_SL to the helper function when it encounters a symlink.

So I think there is a question of who misunderstands the standards - you,
or me and the folk at Compaq/ex-Digital (and I'm quite prepared to allow it
could be the latter - like I say, it ain't clear)

Here's a simple way to resolve the point: In what circumstances (if any) 
will/should glibc:ftw() pass FTW_SL as a value to flag?


------- End of forwarded message -------
Michael Kerrisk
mailto: address@hidden

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."

                E. W. Dijkstra

reply via email to

[Prev in Thread] Current Thread [Next in Thread]