Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KJ Filesystem API #384

merged 5 commits into from Apr 29, 2017

KJ Filesystem API #384

merged 5 commits into from Apr 29, 2017


Copy link

@kentonv kentonv commented Oct 24, 2016

I've long wanted a filesystem API that:

  • Is resistant to path injection bugs.
  • Uses a representation of paths that is easy to manipulate (flat strings with / as separators are actually incredibly tedious!).
  • Canonicalizes ".." logically (by removing the previous path component) rather than physically (by climbing the directory tree), especially when dealing with the current working directory.
  • Is RAII.
  • Does not assume a singleton filesystem (= implements abstract interfaces so that you can provide a different implementation when desired).
  • Throws exceptions on error, but lets you opt-in to programatically handling the kinds of errors that one commonly wants to handle (namely, doesn't-exist and already-exists).
  • Directly supports the write-to-temp-then-atomically-replace pattern.
  • Directly supports the common operations "recursively delete directory" and "automatically create parent directories".
  • Directly supports a copy operation, with smart semantics around sparse files.
  • Makes mmap easy.
  • Automatically opens all file descriptors close-on-exec.
  • Utilizes Linux features like renameat2(), FICLONE (copy-on-write files), O_TMPFILE, etc. when available, but falls back to generic POSIX when not.
  • Much more...

So this is my attempt.

Copy link
Member Author

kentonv commented Apr 7, 2017

(I just merged everything except the filesystem API itself. Github seems very confused about this...)

@kentonv kentonv force-pushed the filesystem branch 3 times, most recently from d13f449 to e0d3908 Compare April 27, 2017 19:27
This has three main parts:
* The Path data structure, a more-explicit approach to file paths.
* The File/Directory abstract interfaces.
* The "InMemory" implementations of File and Directory.

Disk-based implementations will come in a future commit.
Copy link
Member Author

kentonv commented Apr 29, 2017

Gonna merge this because I'm using it in a project, although currently only Ekam will build it. I guess we need a Win32 version before we can make it part of the main builds.

I already cut the 0.6 release branch so this will land in 0.7.

@kentonv kentonv merged commit b1701b8 into master Apr 29, 2017
@kentonv kentonv deleted the filesystem branch April 29, 2017 00:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

Successfully merging this pull request may close these issues.

None yet

1 participant