working on mpp file system, yes

Will this include abstractions for things like zip file systems and virtual file systems (or at least the plumbing to implement them), or are they going to be more focused on actual file systems?

First step is to implement local file systems native to respective platforms. But we’re trying to accomodate for a pluggable design, yes.

In-memory for tests. Zip for reading/writing zips as if they're just normal folders preventing the need to special case them.

Reading resources, on Native from `binaryBlob`s

In-memory for tests

👍

Zip for reading/writing zips as if they’re just normal folders preventing the need to special case them

That’s something I’m not sure about. It requires some special and non-trivial handling of paths, like if I have

/foo/bar/baz.zip!/a/b/c.txt

and then nested zips within zips, etc, etc. I don’t think we will have it in some first version. But ZipFS to open a zip file as a separate

FileSystem

instance and working with it like with an isolated FS will be there.

Reading resources, on Native from `binaryBlob`s

Do you mean specially crafted resource files, like in games (e.g. WAD)?

Do you mean specially crafted resource files, like in games (e.g. WAD)

No, I mean on JVM - resources from jar, on Native something similar, readonly in-memory filesystem compiled and linked to executable file as map (resname : String -> resvalue: CValues)

I think resources in Native were not yet designed (@ilya.matveev). They are processed properly into

processedResources

folder, but not placed into executable. You can zip this folder and use ZipFS to access data.

For zip I only mean as its own file system 👍

In (my idea of the) ideal chronological order of fs path related features: 1. Path object that allows constructing paths to files that works in native and JVM 2. Ability to test if file exists in native/JVM 3. Ability to read/write data

It’s all implemented already. What’s missing before initial 0.1 publish is working with file attributes (exists, isDirectory, isFile already supported, but not very efficient, doing stat on every access)

Please reconsider having the Path know its FileSystem. It means paths cannot be value objects, and not being a value object wrecks many useful things

One case this has bitten me (with nio) is when you have a parent and child Path on FileSystem A which you relativize into a new Path. Then, you use that relative Path to take a base Path on FileSystem B to create a new child. With nio this is an invalid operation because you cannot use Paths across FileSystems. You are forced to

toString()

the relative Path from the FileSystem A and resolve a child on the FileSystem B using the string form. Happens when mounting zip/jar/aars as FileSystems all the time.

Yep, I was thinking about this and I’d make a universal path class, but I don’t yet know how to solve a couple of issues. First is that convenience methods cannot be implemented on

Path

, such as

myFile.openInput()

, and user will have to pass around

FileSystem

instance around. Of course, convenience API could use default FS, but then most of code will be doing exactly this. Second, there are properties on the

Path

that depend on the File System, such as

\

or

/

, allowed characters, etc. This is lesser problem, implementation could accept both separators, but then how to implement

toString()

? Should it be

toString(fs)

? I don’t say it’s impossible to solve this, or prove it is not solvable, I just didn’t give it enough thought yet. I did what’s easiest to have it working somehow.

For convenient APIs to open a stream,

FileSystem.SYSTEM.open(path)

isn’t short but it's very straightforward

If you want to work with whatever FS is given by external code (mock in tests, system, or zip), you need to pass

FileSystem

instance around. This is a major inconvenience. Instead of having a function like

fun loadData(path: Path)

or even

fun Path.loadData()

you will have to have

fun Path.loadData(fs: FileSystem)

and pass these two parameters all they way down to the code that opens a stream. Also, working with nullable paths becomes a pain.