MFS Directory vs UnixFS/IO Directory

[schomatis]

The mfs and the unixfs.io packages have both a Directory structure (the first containing the second) and both implementing an AddChild function (used in combination to add files/dirs to the MFS filesystem) which makes the code hard to understand when reading the MFS work flow (see #5081). It would seem that the rationale behind this is to have MFS representing an abstract directory and UnixFS providing the actual node to support that (but that is just my speculation).

The MFS Directory names its inner UnixFS/IO Directory as dirbuilder (without any comment) which makes it hard to understand their relationship besides what was previously mentioned,

https://github.com/ipfs/go-ipfs/blob/7853e53860805e08a212d78c4baa5d59bff99ba8/mfs/dir.go#L26-L41

https://github.com/ipfs/go-ipfs/blob/7853e53860805e08a212d78c4baa5d59bff99ba8/unixfs/io/dirbuilder.go#L28-L36

My main question right now is: what is the purpose of unixfs.io.Directory? If I understand correctly unixfs.FSNode is the UnixFS representaion for the directory, mfs.Directory is the same at the MFS layer, why is part of the UnixFS functionality regarding directories in a different structure (in unixfs.io.Directory)?

[Stebalien]

unixfs.io.Directory exists for creating/reading/editing directories. However, it doesn't care about directory trees, propagating updates to parent directories, receiving updates from children, etc. It just allows one to perform explicit edits on a single directory.

mfs.Directory, on the other hand:

• Handles concurrent updates (hopefully...).
• Updates the directory when a child changes.
• Signals the parent when it changes.
• Caches children for better performance with rapid lookups/edits.

[schomatis]

I see, my main question is why do we need another structure to encapsulate that functionality, why isn't it absorbed by either the UnixFS or the MFS layers. Let me dig deeper into the code and get back to you.