We now have bunch of involved code for working with file system objects.

Someday it might be good to codify this into a new libnixfile. (Don't worry, that doesn't mean I am planning a "file-only" Nix!) But going down that road would mean lots of little libraries, which could have implications for dynamic linking. For now we can instead group files into subdirectories (see build/ in libstore for this same concept), but keep all such directories linked together in the parent library.

For initial contents I am thinking:

• src/libutil/archive
• src/libutil/canon-path
• src/libutil/fs-sink
• src/libutil/git.cc will contain more stuff after Git object hashing in libstore #8918
• src/libutil/posix-source-accessor
• src/libutil/source-accessor
• src/libutil/file-content-address New, doesn't distinguish between "flat" and "text" because w.r.t file system objects (as opposed to store objects) they are the same.

I think this will continue growing too based on our current plans. libnixfetchers only barely depends on the store layer anyways, so I think some or even all of it could end up here too.