the invention is directed to techniques for accessing a data storage system having both a filesystem and directory system by determining , in response to an instruction for accessing a portion of the data storage system , whether the portion is a file of the filesystem or a directory entry of the directory system , and then accessing that portion of the data storage system appropriately . accordingly , an application developer can develop an application having commands with common or standard names and expressions , such as those for accessing files of filesystems ( e . g ., using the same syntax as that for posix calls ), and rely on this determination ( e . g ., performed by the operating system of a computer ) for proper operation and processing of the application . such an application will be more portable than applications which rely on vendor - specific apis , e . g ., lightweight directory access protocol ( ldap ) apis such as the ldap c , adsi and cns / ad apis . in particular , such an application can access directory entries using a file - like api ( e . g ., posix - like ) and not worry about manipulating ldap information such as directory entry locations , port numbers , etc . fig3 shows a computer system 50 which is suitable for use by the invention . the computer system 50 includes a first computer 52 - a , a second computer 52 - b , a third computer 52 - c , and a network connection 54 which enables the computers 52 - a , 52 - b , 52 - c to communicate . the computers 52 - a , 52 - b , 52 - c ( collectively , the computers 52 ) include respective unix filesystems 56 - a , 56 - b , 56 - c ( collectively , the filesystems 56 ). the computer 52 - b further includes an ldap directory system 58 - b . as shown in fig3 the unix filesystems 56 include files 60 which are organized logically into an inverted tree configuration . similarly , the ldap directory system 58 - b includes directory entries 62 which are organized logically into an inverted tree configuration . an ldap directory entry 62 of the ldap directory system 58 - b is logically coupled with a file 60 , i . e ., a mount point , of the unix filesystem 56 - a , as illustrated in fig3 by the dashed line 64 , i . e ., a mount relationship . this mount situation is similar to a network filesystem ( nfs ) mount in that a data storage system ( namely , an ldap directory system ) of one computer ( i . e ., computer 52 - b ) is mounted to a mount point of another computer ( i . e ., computer 52 - a ) through the network connection 54 . in the arrangement of fig3 any of the computers 52 can view and access the ldap directory system 58 - b . for example , the computer 52 - b can view and access the ldap directory system 58 - b locally . additionally , the computers 52 - a and 52 - c can view and access the ldap directory system 58 - b remotely . in particular , any of the computers 52 can view and access the ldap directory system 58 - b by navigating or traversing a data storage system 70 ( fig4 ) formed by the unix filesystem 52 - a and the ldap directory system 58 - b . that is , the directory entries ( or entries ) of the directory system 58 - b are visible below the mount point as files of the filesystem 52 - a . furthermore , in accordance with the invention , data within the directory entries are accessible using file - like system calls . alternatively , applications can operate as ldap clients and communicate with the computer 52 - b as an ldap server in a typical ldap manner . further details of these features of the invention will now be described with reference to fig4 and 5 . fig4 shows a logical diagram of the data storage system 70 formed by the unix files system 56 - a of the computer 52 - a , and the ldap directory system 58 - b of the computer 52 - b . in particular , the unix filesystem 56 - a includes multiple files such as the root 72 ( called “/”) and a file 74 ( called “ directory ”). the directory system 58 - b includes multiple directory entries including an ldap directory entry 76 ( called “ ou = people ”) and another ldap directory entry 78 ( called “ uid = dsmith ”). the ldap directory entry 76 logically mounts to a mount point under the unix file 74 to maintain an inverted tree configuration for the data storage system 70 . preferably , a user or an application can navigate around files and mounted ldap directory entries of the data storage system 70 in a manner similar to that for navigating a filesystem . in the arrangement of fig4 and by way of example only , a user can perform standard unix navigation operations such as listing child nodes beneath a current location ( e . g ., “ ls ”) and changing from one current location to another ( e . g ., “ cd ”. as another example , an application developer can develop application code 80 which includes common file access commands ( e . g ., “ open ( )”) to access data within one or more ldap directory entries . as shown in fig4 application code 80 , which uses commands having standard file access command names and expressions , can be compiled and linked to generate an executable application having instructions which access data 82 from an ldap directory entry 78 based on those commands . further details of this feature of the invention will now be provided with reference to fig5 . fig5 shows a computer 90 which is suitable for use as any of the computers 52 of the computer system 50 of fig3 . the computer 90 includes a network interface 92 ( e . g ., for interfacing with the network connection 54 ), memory 94 and a processor 96 . the memory 94 consists of several memory constructs such as an application 98 and an operating system 100 . the operating system 100 includes , among other things , a mount list 102 and an interface 104 ( e . g ., a system call interface ). the memory 94 may further include other memory constructs such as a filesystem 106 and a directory system 108 . for example , each of the computers 52 - a , 52 - c includes a respective unix filesystem 56 - a , 56 - c , but does not include a directory system ( see fig3 ). additionally , the computer 52 - b ( an ldap server ) includes both a unix filesystem 56 - b and an ldap directory system 58 - b . in one arrangement , a computer program product 110 ( e . g ., one or more cdroms , tapes , diskettes , etc .) provides one or more of the above - described memory constructs to the computer 90 . for example , the computer program product 110 may include both the application 98 and the operating system 100 . in this example , the operating system 100 and the application 98 can be installed on the computer 90 , and then invoked to create other memory constructs such as the directory system 108 . the cisco ios manufactured by cisco systems of san jose , calif . is suitable for use as the operating system 100 . as an alternative example , the computer 90 can acquire the application 98 through other means , e . g ., via a network download through the network interface 92 . the operating system 100 supports a directory storage system 108 with object - classes ( e . g ., a directory entry object class ) which enables the operating system 100 to treat directory entries of the directory system in a file - like manner . furthermore , the directory entries , which are to be treated in the file - like manner by the operating system , include a “ whole data ” attribute . as such , when the operating system 100 accesses a portion of a data storage system having both files and directory entries and determines that the portion is a directory entry , the operating system 100 can provide information from the directory entry in ldap data interchange format ( ldif ), a popular format that describes directory entry information as text files . however , if the directory entry has a different object class ( e . g ., a file object class ), the controller 111 can provide the information in a different , non - ldif format ( e . g ., store a file in the directory entry ). this mechanism of storing files in a directory system can be made into a standard through the internet engineering task force ( ietf ) ldap extension group . during operation , the processor 96 runs the operating system 100 to form a controller 111 which processes instructions 112 ( e . g ., application instructions , command line user instructions , etc .). the controller 112 includes a determining module 114 and an operation performing module 116 . the determining module 114 determines , for each data access instruction ( e . g ., open ( ), read ( ), write ( ), etc .) of the instructions 112 , whether that data access instruction targets a file of a filesystem ( e . g ., files 72 , 74 in fig4 ) or a directory entry of a directory system ( e . g ., directory entries 76 , 78 in fig4 ). the determining module 114 then provides a signal 118 to the operation performing module 116 indicating whether that data access instruction targets such a file or a directory entry . the operation performing module 116 executes the instructions 112 . in particular , when the operation performing module 116 executes the data access instructions , the module 116 performs data access operations based on the signal 118 which indicates whether the data access instructions target files or directory entries . accordingly , application developers can develop applications ( e . g ., the application 98 ) which use a file - like interface to access information ( e . g ., network information ) within a directory system ( e . g ., the directory system 108 ). fig6 shows a procedure 120 that is performed by the controller 111 when encountering a mount request ( e . g ., a mount system call ). in step 122 , the controller 111 receives the mount request identifying ( i ) a mount point of a filesystem and ( ii ) a mount target . in step 124 , the controller 111 determines whether the mount target is a directory entry of a directory system or a file of a filesystem . in one arrangement , the controller 111 checks an object class ( or datatype ) of the mount target to make this determination . if the mount target is a file of a filesystem , step 124 proceeds to step 126 . if the mount target is a directory entry of a directory system , step 124 proceeds to step 128 . in step 126 , the controller 111 has determined the mount target to be a file of a filesystem and mounts the file to the mount point . in particular , the controller 111 performs this mount operation in a conventional manner by establishing a mount relationship within an entry of the mount list 102 of the computer 90 ( see fig5 ), e . g ., a posix mount ( ) operation . in steps 128 through 132 , the controller 111 has determined the mount target to be a directory entry of a directory system , and mounts the directory entry to the mount point . in step 128 , the controller 111 initializes an ldap server for operation ( e . g ., by performing an ldap_init ( ) operation ). in step 130 , the controller 111 preferably performs a login operation for authentication purposes ( e . g ., by performing an ldap_bind ( ) operation ). then , in step 132 , the controller 111 updates the mount list 102 of the filesystem . accordingly , the directory system is mounted to the filesystem . once the controller 111 completes the procedure 120 thus mounting the directory system to the filesystem , the directory system is essentially integrated into the global name space of the filesystem from the perspective of the operating system 100 . accordingly , an interactive file - manager running on the computer 90 , which shows the filesystem in an inverted tree hierarchy , will logically show ( to a user ) the directory entries of the directory system as files . as such , double - clicking on a directory entry ( which the file - manager displays as a file ) will make information within the directory entry available to the user ( e . g ., in ldif format ). a directory browser can also access the directory entries of the directory system but such a browser is no longer required . with reference to fig3 through 6 and by way of example , when mounting the directory system 58 - b to the filesystem 56 - a ( see fig3 ), the mount point is a file called “ people ” of the filesystem 56 - a , and the mount target is an ldap directory entry called “ ou = people ” of the ldap directory system 58 - b . the application 98 running on the computer 90 ( see fig5 ) provides the controller 111 with a mount request ( step 122 ). the determining module 114 determines that the mount target of the request is an ldap directory entry ( step 124 ), and provides the signal 116 indicating that the mount target is an ldap directory entry . based on the signal 116 , the operation performing module 118 then initializes an ldap server ( e . g ., part of the operating system 100 ), binds the ldap directory entry , and mounts the mount target ( the directory entry called “ ou = people ”) to the mount point ( steps 128 through 132 ). upon completion of the mount operation , the filesystem 56 - a and the directory system 58 - b form the data storage system 70 , which is logically illustrated in fig4 and 3 . fig7 shows a procedure 140 which is performed by the controller 111 when 10 encountering an open request ( e . g ., an open ( ) system call ). in step 142 , the controller 111 receives the open request which identifies a portion of the data storage system 70 including the unix filesystem 56 - a and ldap directory system 58 - b . in step 144 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 144 proceeds to step 146 . if the identified portion is an ldap directory entry , step 144 proceeds to step 148 . in step 146 , the identified portion is a unix file and the controller 111 opens the unix file in a conventional manner ( e . g ., a posix open ( ) operation ). in particular , the controller 111 , among other things , retrieves a file descriptor for identifying the file . in step 148 , the identified portion is an ldap directory entry and the controller 111 performs an ldap open operation . in particular , the controller 111 initializes internal data structures for a file with a distinguished name of the directory entry of the directory system ( e . g ., “ ou = people ”, see fig3 and 4 ). accordingly , the controller 111 has now opened the directory entry of the directory system for access by an application . fig8 shows a procedure 150 which is performed by the controller 111 when encountering a create request ( e . g ., a creates system call ). in step 152 , the controller 111 receives the create request which identifies a portion of the data storage system 70 that includes the unix filesystem 56 - a and ldap directory system 58 - b . in step 154 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 154 proceeds to step 156 . on the other hand , if the identified portion is an ldap directory entry , step 154 proceeds to step 158 . in step 156 , the identified portion is a unix file and the controller 111 creates the unix file in a conventional manner ( e . g ., a posix creates operation ). in step 158 , the identified portion is an ldap directory entry and the controller 111 performs an ldap add operation . in particular , the controller 111 adds an entry to the ldap directory system of the data storage system 70 . the controller 111 distinguishes the entry from other entries by providing a unique attribute for the entry . accordingly , the controller 111 has now added a directory entry to the directory system . fig9 shows a procedure 160 which is performed by the controller 111 when encountering an unlink request ( e . g ., an unlink system call ). in step 162 , the controller 111 receives the unlink request identifying a portion of the data storage system 70 which includes the unix filesystem 56 - a and ldap directory system 58 - b . in step 164 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 164 proceeds to step 166 . in contrast , if the identified portion is an ldap directory entry , step 164 proceeds to step 168 . in step 166 , the identified portion is a unix file and the controller 111 unlinks the unix file in a conventional manner . in particular , the controller 111 removes the unix file from the filesystem . in step 168 , the identified portion is an ldap directory entry and the controller 111 performs an ldap delete operation . in particular , the controller 111 deletes an existing entry to the ldap directory system of the data storage system 70 . accordingly , the controller 111 has now removed the directory entry from the directory system . fig1 shows a procedure 170 which is performed by the controller 111 when encountering a read request ( e . g ., a read ( ) system call ). in step 172 , the controller 111 receives the read request which identifies a portion of the data storage system 70 including the unix filesystem 56 - a and ldap directory system 58 - b . in step 174 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 174 proceeds to step 176 . otherwise , if the identified portion is an ldap directory entry , step 174 proceeds to steps 178 through 188 . in step 176 , the identified portion is a unix file and the controller 111 reads data from the unix file in a conventional manner ( e . g ., a posix read ( ) operation ). in steps 178 through 188 , the controller 111 reads data from the ldap directory entry . in step 178 , the controller 111 performs an ldap search ( or filter ) operation to find the identified directory entry within the ldap directory system . in step 180 , the controller 111 performs an ldap first entry operation to obtain the identifier ( id ) of the ldap directory entry ( also referred to as an ldap entry ). in step 182 , the controller 111 performs an ldap first attribute operation to obtain the first attribute of the ldap entry identified by the identifier obtained in step 180 . in step 186 , the controller 111 can obtain additional attributes by performing ldap next attribute operations . in step 188 , the controller 111 gets values from the identified ldap entry . the result of performing steps 178 through 188 is data which has been extracted from an ldap entry in a manner that is transparent to the application 98 which provided the initial read instruction to the controller 111 ( i . e ., no need to specify whether target is ldap entry or unix file ). in one arrangement , the controller 111 checks the object class of the ldap entry prior to reading information from the entry . if the entry has a normal object class , the reads the information in ldap data interchange format ( ldif ), a popular format that describes directory entry information as text files . however , if the directory entry has a different object class ( e . g ., a file object class ), the controller 111 can store the information in a different , non - ldif format ( e . g ., store a file in the directory entry ). fig1 shows a procedure 190 which is performed by the controller 111 when encountering a write request ( e . g ., a write ( ) system call ). in step 192 , the controller 111 receives the write request which identifies a portion of the data storage system 70 having the unix filesystem 56 - a and ldap directory system 58 - b . in step 194 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 194 proceeds to step 196 . however , if the identified portion is an ldap directory entry , step 194 proceeds to steps 198 through 200 . in step 196 , the identified portion is a unix file and the controller 111 writes data to the unix file in a conventional manner ( e . g ., a posix write ( ) operation ). in steps 198 through 200 , the identified portion of the data storage system 70 is an ldap entry . in step 198 , the controller 111 parses the information into an ldap compatible format ( e . g ., converts a stream of bytes into a list of attributes and values ). in step 200 , the controller 111 stores the parsed information in the ldap directory entry by performing an ldap modify operation ( e . g ., ldap_modify ( )). accordingly , the controller 111 has now written information into the directory entry of the directory system . fig1 shows a procedure 210 which is performed by the controller 111 when encountering a readdir request ( e . g ., a readdir ( ) system call ) to obtain information regarding a particular portion of the data storage system 70 ( e . g ., for the unix “ ls ” command ). in step 212 , the controller 111 receives the readdir request which identifies the portion of the data storage system 70 having the unix filesystem 56 - a and ldap directory system 58 - b . in step 214 , the controller 111 determines whether the identified portion of the data storage system 70 is a unix file or an ldap directory entry . if the identified portion is a unix file , step 214 proceeds to step 216 . on the other hand , if the identified portion is an ldap directory entry , step 214 proceeds to steps 218 through 222 . in step 216 , the identified portion is a unix file and the controller 111 obtains information regarding the unix file in a conventional manner ( e . g ., by performing low level operations for the unix “ ls ” command ). in steps 218 through 222 , the identified portion of the data storage system 70 is an ldap entry . in step 218 , the controller 111 performs an ldap search operation to find the ldap entry within the ldap directory system . in step 220 , the controller 111 performs an ldap first entry operation to obtain an identifier ( id ) of the ldap entry . in step 222 , the controller 111 gets and returns values from the identified ldap entry in order to satisfy the readdir request . accordingly , the controller 111 has now obtained directory entry information of the directory system for use in navigating ( e . g ., for the “ ls ” and “ cd ” commands in unix ) the data storage system as if it were exclusively a filesystem . it should be understood that other types of requests ( e . g ., other system calls ) can be configured to operate in manners similar to that described above for handling the more common types of access requests ( e . g ., open , create , read , write , etc . shown in fig6 - 12 ). by handling such requests using a file - like interface ( e . g ., posix - like ), application developers can develop more portable applications ( e . g ., without relying on a particular ldap api such as ldap c , adsi and cns / ad ). additionally , the arrangement is well - suited for applications that access data such as network information ( e . g ., network configuration information and policy definitions ), security and authentication data ( e . g ., passwords ), and personnel information ( e . g ., names and addresses ). the features of the invention may be particularly useful in computerized devices manufactured by cisco systems , inc . of san jose , calif . while this invention has been particularly shown and described with references to preferred embodiments thereof , it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims . for example , there is no set number of computers required for the invention . three computer were shown in the arrangement of fig3 by way of example only in order to illustrate a situation where any of the three computers will be able to access the data storage system 70 ( also see fig4 ) formed by the unix filesystem of the computer 52 - a and the ldap directory system 58 - b of the computer 52 - b . other arrangements may include different numbers of computers . for example , another arrangement may include a single computer having both a filesystem and a directory system in a local memory ( e . g ., disk memory , semiconductor memory , etc .). additionally , it should be understood that the topology of the computer system 50 is provided by way of example only . other topologies are suitable for use by the invention as well ( e . g ., token ring , hub - and - spoke , etc .). furthermore , it should be understood that the data storage system 70 , as shown in fig4 can be formed by a filesystem other than the unix filesystem and directory systems other than the ldap directory system . for example , the data storage system 70 can use a windows / nt filesystem rather than the unix filesystem . in such an arrangement , the procedures for responding to access requests ( e . g ., see fig6 - 12 ) can be configured to handle windows / nt access operations when the identified portion of the data storage system is a windows / nt file .