In-Memory FileSystem in Java - Is there a better OOP approach?
create Subclasses / interfaces
if you think there is a difference in Behaviour then there is a need for a seperate class - if you think some classes have something in common, extract an interface!
so create a class Directory and a class File. Let both classes implement the Node Interface. (Note - in Java we don't use the hungarian notation )
inconsistency // oo-abuse
what's the purpose of Node if you don't use it? compare these two approaches

public List&lt;String&gt; ls(String path) vs.
public List&lt;Node&gt; ls(Node path)

in case 1 it is absolutly not clear how the String path should look like, especially since it is OS-dependant. (what would String[] subdirs = filePath.substring(1).split(&quot;/&quot;); on other OS do?) It is also not clear what kind of output this Method delivers
in case 2 we have cleary declared what kind of input we expect, (even though i'm missing a parent attribut - that would ease up the searching) - we reduce the problem with different OSes to the single place where it belongs: at the constructor of the Node (Single responsibility). And we have a very accurate output (compared to the List&lt;String&gt; from case 1 - how would we know if a String is a Directory or a File? Node already provides all these information!)
File System vs. Editor
i'm not sure how addContentToFile() and readContentFromFile match for a FileSystem - in my opinion these two methods belong to an Editor/Viewer and not the the File System - create an Editor (an Editor class)!
think of the possibilities: you can then provide different Editors for different file Types?
Error Handling
i would expect a file system to be a bit more chatty about IllegalArgumentException (why are none thrown? how is such case treated?)