> > That could be done. Did you look at ftw(3C)/nftw(3C)?
> >
> Yes, the current usage is nftw(3C) followed by a sort -u of the
> final records (which start with the fullpathnames.) This requires
> linear heap growth with regard to the size of the manifest.
>
> With the fts(3) routines I can do fts_open on each starting point
> and use a compare function to build the XML manifest in directory order.
> This should eliminate generating records twice and keep the memory
> footprint constant (with regards to manifest size) for xml create and
> compares for large filesystems.
OK, sounds like a better interface. Let's try to go that way.
Send me the supplier and consumer information and I'll start
the contract process:
2. The SUPPLIER (definer and/or implementor) is identified by the following:
Product or Bundle:
Consolidation:
Department or Group:
Bugster Product/Category/SubCategory:
Responsible Manager:
3. The CONSUMER is identified by the following:
Product or Bundle:
Consolidation:
Department or Group:
Bugster Product/Category/SubCategory:
Responsible Manager:
Gary..
