Files In Dib Directory


Files In Dib Directory

NDS.LCK - Lock File#

While performing database maintenance with DSRepair, you must sometimes close or lock the eDirectory database for modifications. The NDS.LCK file is used to designate this locked condition. For eDirectory 8.5 and 8.6 this file will show as a 0 byte file. When the database is locked attributes are changed on this file to signify that condition. It will still show as a 0 byte file. You will notice that the time stamp of the file is updated whenever the database is locked or unlocked.

  • *.FRS files are temporary files used by the eDirectory database, FLAIM, for sorting and merging index records. (FRS stands for Flaim Result Set). You are best advised NOT to delete them when eDirectory is up and running. If you do, unexpected results will occur, even system failures.
  • nds.conf = bootstrap configuration for eDirectory server and the DIB

NDS.DB - Roll Back Log#

DIB header and data records and more.

Changes to the eDirectory database can include large operations which require many packets' worth of information to be sent to the server. eDirectory commits each packet to the database as it is being received-even though the entire transaction may not yet be complete.

To safeguard against communication failure, eDirectory writes these transactions to a Roll Back log. If an incomplete operation is encountered, eDirectory can use this Roll Back log to undo incomplete transactions.

nds.01 .. nds.x7t#

The NDS.01 and subsequent database files are the main eDirectory database files. They can contain almost all data relating to eDirectory objects and their attributes.

The NDS.01 database contains several types of records and also any eDirectory indexes defined on the server. Records found within this database fall into the following basic types:

  • Entry records
  • Partition records
  • Attribute records
  • Schema records
The NDS.## files can grow to a maximum size of almost 4 GB for DS version 8.6 and and greater. When the maximum size is reached, additional database files (starting with NDS.02) are created. The entire eDirectory database can grow into several terabytes' worth of data.

NOTE: EDirectory Versions prior to 8.6 use a maximum size of 2 GB for the NDS.01 file. When the 2 GB size limit is reached, a new NDS.02 file is created. If more than one NDS.xx file exists prior to upgrading to eDirectory 8.6, the 2-GB limit will be imposed on all subsequent NDS.xx files. If only one NDS.01 file exists prior to the upgrade, it will be allowed to grow to the full, almost 4 GB, size.


Tunable parameters for the FLAIM database such as cache size can be statically assigned as a hard limit or dynamically configured by eDirectory.

This file should NOT be edited directly without Novell Support direction.

If the cache size is statically assigned, the _NDSDB.INI file will be created in the dib directory. This is accomplished by using a SET DSTRACE parameter.

SET DSTRACE=!MB<amount_of_RAM_to_use_in_bytes>

For example, to set a hard limit of 8 MB you would type the following command at the console:


This command will set a persistent setting in a file called _NDSDB.INI file found in the dib directory. The following represents the cache parameter that would be set in the _NDSDB.INI file when using the SET command above for 8MB:


*ndo.* #

Backups of DIB data records (For a version 8 database)from NDSREPAIR -RC


Backups of DIB data records (For a version 7 database). from NDSREPAIR -RC

NDS.RFL\xxxxxxx.LOG - Roll-Forward Logs#

Roll-Forward Log. Moved into a separate sub-directory (nds.rfl/) from 8.6 and greater.

To protect against loss of data from a catastrophic failure such as a server crash, eDirectory incorporates a Roll-Forward Log to track all changes made to the eDirectory database. The Roll-Forward Log naming convention starts at 00000001.LOG and, as needed, increments to FFFFFFFF.LOG. If necessary, eDirectory can recommit lost data to the database by examining the xxxxxxx.LOG files when the server is restarted.

As records are modified in the eDirectory DIB, but before those records are committed to the disk, a copy of the changes is entered into the Roll-Forward Log file. These entries are completed transactions that had not been written to disk. Upon server failure, the records committed to the disk may be lost, but the changes will be maintained in the Roll-Forward Log. This process is handled by the FLAIM checkpoint thread on the server and this file should decrease in time as transactions are written to disk.

The Roll-Forward Logs are typically stored in the <system>\NDS.RFL directory. Starting with With eDirectory 8.7 it is possible to store this file in a different location. To ensure database integrity, it is recommended to place the Roll-Forward Logs on a disk other than the one holding the eDirectory database. This will be accomplished by using the backup and restore utility. It is possible to delete this file but it is NOT recommended.

Temporary Files / Repair Local Database#

When running DSRepair and repairing the local database, one option is to use a temporary NDS database during the repair. This allows the repair operation to be done on copy of the database and not the live database. The following files are created during this time.
  • NDT.DB
  • NDT.01
  • NDT.RFL\0000001.LOG

When the repair is completed normally and the database is unlocked these files are removed.

*.TAO and *.WBK files DirXML#

DirXML uses *.TAO and *.WBK files for transaction information. Those files are stored in the DIB directory and, like all files in the DIB directory, should not be touched. The DirXML.LOG and any other logs (ndsdstrace, javatracefile, etc...) can be deleted as desired, with due diligence.



More Information#

There might be more information for this subject on one of the following: