This opens some interesting possibilities:
- updatedb need only run on directories that have been changed;
- more-sophisticated versions of updatedb (full-text indexing? stat
data?) could become feasible to update rapidly;
- locate could manually search directories that are newer than updatedb's
last run, meaning locate could give correct results
- find could be implemented in terms of locate (except for -atime)
- so find would run in time proportional to the number of files you had
updated since the last updatedb, instead of time proportional
to the number of files on your disk. This is likely to be even
more useful as filesystems expand from millions of files to
hundreds of millions of files (if reiserfs takes off).
. . . of course this would require that the mtime updates happen
recursively, all the way down to the root of the filesystem.
I believe NT 4 does this already.
. . .but it breaks Unix semantics. So it shouldn't be the mtime,
except possibly for certain particular cases.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> According to my medieval text in the seventh century a finalizer raised a dead object named Gorth who infected every computer in Cappidocia ending Roman rule in the region. -- Charles Fiterman on gclist@iecc.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/