Pure-Go filesystem drivers — read & write disk images, no cgo, no root.

go-filesystems is a set of independent, dependency-free Go modules that read and write on-disk filesystem images — one module per filesystem, all implementing a small shared contract. No cgo, no root.

The contract lives in go-filesystems/interface:

// package filesystem
type Filesystem interface {
	Close() error
	ReadFile(path string) ([]byte, error)
	ListDir(path string) ([]DirEntry, error)
	Stat(path string) (Stat, error)
	WriteFile(path string, data []byte, perm os.FileMode) error
	ReadLink(path string) (string, error)
	MkDir(path string, perm os.FileMode) error
	DeleteFile(path string) error
	DeleteDir(path string) error
	Rename(oldPath, newPath string) error
}

	Module	Filesystem	On-disk format
	apfs	Apple File System.	Real APFS on-disk (kext-mountable), GPT-aware
	btrfs	Copy-on-write Linux fs; read-only subvolumes/snapshots.	Single-device, CRC32c (btrfs-progs ≥ 5.x)
	exfat	Extended FAT for large media.	exFAT
	ext4	Linux ext4 — extents, 64-bit, journaling, metadata_csum.	ext4 — extents, 64-bit, flex_bg, dir htree, metadata_csum (CRC32c)
	fat32	FAT with 32-bit allocation.	FAT32
	ffs	NetBSD/OpenBSD Berkeley Fast File System.	FFSv1/FFSv2 (= UFS1/UFS2), re-export of ufs
	hfsplus	Apple HFS+ / HFSX (Mac OS Extended).	Big-endian catalog + extents-overflow B-trees
	iso9660	ISO 9660 / ECMA-119 optical-disc filesystem.	ISO 9660 / ECMA-119 + Rock Ridge (names/perms/symlinks) + Joliet (UCS-2 names)
	ntfs	Windows NT filesystem.	Minimal in-image blob model — NOT the real NTFS on-disk format; separate read-only real-NTFS reader
	squashfs	Compressed read-only archive filesystem.	SquashFS 4.0 read-only archive; gzip/xz/zstd/lzo/lz4 blocks + fragments
	uefi	EFI System Partition (FAT-based).	OVMF/EDK2 NvVar variable store; time-based authenticated writes
	ufs	Unix File System (BSD).	UFS2 (FreeBSD 14.x) read+write; UFS1 read; NetBSD/OpenBSD FFSv1/FFSv2 (via ffs alias module)
	xfs	High-performance journaling filesystem.	XFS v5 (CRC32c, ftype), reflink + quotas
	zfs	Copy-on-write pooled storage filesystem.	Single pool, single-vdev writer; multi-vdev/RAID-Z read
	oci	Read-only OCI/Docker image filesystem.	Merged tar-layer overlay (whiteouts, opaque dirs, hardlinks) — image-as-filesystem, not an on-disk format

Also in the org: detect, a blkid-style type prober and driver-opener registry that dispatches to the drivers above (not an on-disk format, so it has no row here).

More drivers are added over time. This table is the on-disk formats; the sections below carry the rest of the org, which it used to claim to cover and did not — nine repositories were named on no page at all.

Not on-disk formats, so they have no row above — but each one answers the same filesystem.Filesystem contract, so anything that walks a disk image walks these too.

It has no row in the section above on purpose. Two modules needed this parser and needed different filesystems over it: unarchive indexes into an io.ReaderAt it keeps open, rpm has the whole payload decompressed in memory. Sharing the filesystem would have meant one of them taking the other's shape; sharing the parser costs neither anything — and the parser is where the defects live.

The other direction: take any driver above and put it on a port, so a machine that cannot link Go can still read the image.

Not serving to a foreign client, but splitting one filesystem across two processes so the one that touches the files need not be the one that talks to the network. Serve answers requests against any driver above; New is that driver at the other end of the connection, with the same optional interfaces and the same errors — an errno comes back as itself, so errors.Is(err, fs.ErrNotExist) answers as it did on the server.

go-fileshare/fileshare uses it to serve a person's files as that person: a worker under their uid holds the directory, behind a front that parses SMB, WebDAV or SFTP and holds no privilege. Neither side trusts the other's bytes — every frame and every field in it is bounded before anything is allocated for it.

Every driver above decodes a format out of an image. This one does not: it hands each call to the host kernel, relative to one directory, so a server from the section above can serve a plain directory with no image in the way.

Copying a range out of one driver and into another normally means pulling it through this process. When both ends are files of the host, it does not have to: the kernel can be asked to do the copy and the bytes never arrive here.

Read = open & inspect images · Write = mutate in place · Format = create a fresh image. Per-driver details on the docs site.

Legend: ✅ supported by the driver · ✕ not yet implemented (the on-disk format has the feature) · — not applicable (the format has no such feature). Read = open & inspect · Write = mutate in place · Format = create a fresh image · Label = volume label (Labeller). Quota / Snapshots / Encryption reflect what the driver implements today.

• 📖 Docs — https://go-filesystems.github.io/docs/
• 🌐 Site — https://go-filesystems.github.io/
• 🧩 Interface — https://github.com/go-filesystems/interface
• 🎨 Brand assets — https://github.com/go-filesystems/brand

_{Branding in go-filesystems/brand.}