What about this loop is faster than the existing lookup? It looks like it's doing the same logic, just surfacing it out of LFNIndex and thereby avoiding a few vector copies?
Also, Sam is insistent that the HashIndex is responsible for how we split up files among subcollections (ie, dirs), but not for directly turning a hierarchy (the vector<string> used elsewhere) into an actual filepath (because those paths are mangled, involve system-specific separators, etc). If this is important you could push it down into the LFNIndex with an interface better-suited to efficiency than the current one.