Home
There's a number of ideas for future Duc development that end up in old issue tickets and are slowly forgotten. I put them up here as a reminder to myself, and hopefully as a list for prospect contributors.
Doc has a list of all inodes in each directory, and the mtime of that directory. It could use this info to traverse the file system as long as the mtimes between the database and the file system match. I've done a proof of concept of this once which resulted in a huge speedup, but the code never made it into Duc because the implementation was too dirty. Some refactoring needs to be done before first.
I've been asked a number of times if Duc can provide delta's between two indexes so the growth or shrinkage of a filesystem can be visualized. This does not at all fit in the current architecture, though.
Most PC's have more then one CPU these days, but Duc does not profit from this at all. Indexing could probably be sped up a bit if threading or some other parallelization is used. This would also benefit indexing of RAID file systems running on multiple spindles, or indexing of trees on different physical devices at the same time.
Not sure about this one, but for some cases it would be nice to watch the file system for changes in real time and have Duc update the database right away.