Gary Winiger wrote:
>> It does not looks like solaris' libc has anything appropriate, but I
>> see that libast includes ftwalk(3) and beneath that is what looks like a
>> general purpose fts(3) implementation which is what is really needed.
>> (libast is ksh93 project private in PSARC/2006/550)
>>
>> I'd like to use fts_open(), fts_read(), etc in my prototype and ask
>> our ARC sponsor to setup a contract for these interfaces if that is
>> agreeable to members of the ksh93 project?
>>
>
> 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.
-Will
>
> Gary..
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
>
