With the composite pattern, you can easily represent that.
You could have as base class Resource and File and Folder, subclasses of Resource.
And the hierarchical notion would rely on Folder that composes a Set of Resource that can be so File and Folder.
String path and reference to the physical resource fields could be stored in Resources as these have the same representation in both subclasses.
To go further, as you represent data, generally you also want to manipulate them and preferably in a simple and uniform way.
For example as clients want to perform common operations on resource instances (folder or a file) : creating, listing or deleting a resource, etc... it would be simpler for them if they can manipulate a single interface.
The composite pattern allows it.
Just declare in the base class (Ressource) the common operations and let subclasses to define the required behaviors.
That's all.