Declined Splitting JPSTREE.IDX

[Steve Fabian]

With the prevalence of large, portable drives, as well as network mapping of
drives it would make sense to permit splitting up the extended directory
search database so that each drive would contain its own portion, without
drive letters, thus making it possible to utilize the extended search
database regardless of the currently assigned drive letter. It could also
speed up directory searches and reduce update times (except when the target
drive is unknown, and drives much slower than that specified by the current
TreePath directive). I assume there would be a command/option configuration,
or a distributed batch file for automatic conversion for both directions
between old and new style database. With that consideration a few issues
come to mind:

1/ backward compatibility
If significant, the database conversions may be utilized to achieve 100%
compatibility before and after using an older version of the command
processor.

2/ using the database search when the target drive is unknown
In the current method a single database is searched, and all matches are
displayed. This would be more difficult using the new method, requiring
database searches on each drive, potentially slower. However, such searches
are not very likely in batch files, and the additional time during
interactive use is likely to be barely noticeable.
--
Steve

 

[w_krieger]

It also has the advantage that you can create one for the root of a cdrom etc, such as was the way with the older TREEINFO.NCD.

 

[K_Meinhard]

Steve FXbiXn wrote:

> With the prevalence of large, portable drives, as well as network
> mapping of drives it would make sense to permit splitting up the
> extended directory search database so that each drive would contain
> its own portion, without drive letters, thus making it possible to
> utilize the extended search database regardless of the currently
> assigned drive letter. It could also speed up directory searches and
> reduce update times (except when the target drive is unknown, and
> drives much slower than that specified by the current TreePath
> directive). I assume there would be a command/option configuration,
> or a distributed batch file for automatic conversion for both
> directions between old and new style database. With that
> consideration a few issues come to mind:

I'll renew my suggestion to add database, eg. dBase, functionality to
TCC.

You could use it for JPSTREE.IDX, it would probably greatly speed up
the search. And your users would probably find a lot of uses for this
feature. I think it would mak a great and really new feature for the
next
major upgrade.

Another possibility would be to use the technique employed by a proggy
called "Everything" (see http://www.voidtools.com/ ).

Best Regards,

* Klaus Meinhard *
<www.4dos.info>