dirent->d_type: DT_LNK oddness ?

Hiya -

Playing with BSD File routines & it seems that *every*
file I retrieve
info on via readdir that isn't a directory or a pipe/fifo
has "DT_LNK"
set. 

I would have thought that this should only be set for
symbolic links
(cannot be sure, since sys/dirent.h doesn't elaborate on
the enums
listed, and I can find nothing on this via google.

Should I maybe be using something other than readdir to grab
the
contents of a directory ? At this point I'm looking for
file name, and
the type of stuff that (I thought) was included in dirent's
d_type
(whether something is a directory, pipe, link or 'regular'
file).

FWIW, here's a snipped of code that illustrates what I'm
doing:

#include <stdio.h>
#include <sys/types.h>
#include <sys/dir.h>

int main(int argc, char *argv[]) {

        DIR *dirp;
        struct dirent *dp;

        dirp = opendir(argv[1]);
        while ((dp = readdir(dirp)) != NULL) {
                printf("NAME IS : %s",
dp->d_name);
                if (dp->d_type & DT_UNKNOWN)
printf("\t\tUNKNOWN");
                if (dp->d_type & DT_DIR)    
printf("\t\tDIRECTORY");
                if (dp->d_type & DT_LNK)    
printf("\t\tLINK");
                if (dp->d_type & DT_FIFO)    
printf("\t\tPIPE");
                printf("\n");
        }
        (void)closedir(dirp);

    return 0;
} // fin

Thanks for any advice you can throw at me - Dave
 _______________________________________________
Do not post admin requests to the list. They will be
ignored.
Darwin-dev mailing list      (Darwin-devlists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-
dev/bond%40yahoo.com

This email sent to bondyahoo.com

Cost effective IT certification exam resources from the
quality Tuition providers with guarantees at cheap prices
http://www.itdumps.com



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://g
roups.yahoo.com/group/COMPTIA_APLUS/

<*> To unsubscribe from this group, send an email to:
    COMPTIA_APLUS-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.c
om/info/terms/
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Shinta" == Shinta Sugimoto
<shintasfc.wide.ad.jp> writes:
    >> I can see how getsockname()/getpeername() are
not good enough,
    >> and you'd like a more sophisticated answer.
This is similar,
    >> certainly to what IPsec wants: we want to know
far more than what
    >> that interface can provide.  (And in the case
IPv4 transport mode
    >> through a NAPT, the answer from getpeername()
is perhaps
    >> completely ambiguous)

    Shinta> I see.  BTW, is there any other cases than
NAT where IPsec
    Shinta> requires more sophisticated Socket API calls
if peer is
    Shinta> multihomed ?

  Many people would like to be able to establish multiple
IPsec SAs
between two nodes that are multihomed. I.e. one for each
interface
address. Many would like to load balance between the
tunnels.

  (The only situation that I'm aware that have been
deployed is actually
  where one load balances between *machines*, with failover
between the
  two machines, and it's all about tunnels, so the
end-application never
  sees this)

  Given shim6, let ULP=ESP, and just use shim6. So, IPsec in
the kernel
may need to know about shim6, but application does not see
shim6, only
IPsec.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.       
   |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON
   |net architect[
] mcrxelerance.com      http://www.san
delman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel
hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on
Linux." - orospakr



  

  
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys

iQEVAwUBRE4kVICLcPvd0N1lAQJ2cggApEL/9B28gJk9s/IiAvvCn8c9yi9q
aaYW
F0J7hd4Blx+bhB5z+DG2gS6O7soXo1ehtqf731Xu9Kcl+ihUAxBx9gUd9j9E
sXy/
OlxXavKAtKEh8N18CqJh6XJFqWr9m7DCBcYiz+GzIzc/0tgRTFBCidYC4PE4
cNrk
oJq9obxmQJgLVm2vWJIaQEDmtjW1CLymO2o6uwxcCTwJLPDR1N2G7+dGbSUH
+d2m
+7xsPcmdRrQmGFJxutpo9/KF/s5lyOn7SDm3XAbhE0B6oUGsBZtAgWvonZ+b
3KGF
/xcy1EQB6sEMt2w8fgYb6YTts4DqVAP63Or7EgT+U1yg8CQIKnQpNA==
=91Gm
-----END PGP SIGNATURE-----
_______________________________________________