A FileSystem Abstraction System for Go
Go to file
L. Alberto Giménez a4ea980f2d
Add tarfs implementation (reopen #265) (#266)
* Initial commit for tarfs

* tarfs: reword "open" status field

* tarfs: use TestMain for FS setup

We want to have the FS variable available through all the tests, so we
we use a common "setup" function to initialise it.

* tarfs: test: early exit for nonexisting files

* tarfs: create test for filesystem Open

* tarfs: implement File.Stat

* tarfs: implement Fs.Open

* tarfs: return error on non-supported methods

As tarfs is a read-only filesystem backend, we return EROFS (Read-only
file system) from any method that makes modifications.

* tarfs: implement File.data as bytes.Reader

Most of the operations that we want to implement for tarfs.File are
already defined in bytes.Reader.

We could use a plain slice and implement all the seeking manually, but I
think using this is more convenient.

* tarfs: short format for simple methods

* tarfs: add missing closing brace in tests

* tarfs: add test for File.ReadAt

* tarfs: test File.ReadAt

* tarfs: add tests for File.Read

* tarfs: implement File.Read

* tarfs: add tests for File.Seek

* tarfs: implement File.Seek

* tarfs: add tests for File.Name

* tarfs: implement File.Name

* tarfs: add tests for File.Close

* tarfs: implement File.Close

* tarfs: add tests for OpenFile

* tarfs: fix test for Fs.OpenFile

If the call fails, we don't have to close the file

* tarfs: remove code not needed after using filepath.Clean

* tarfs: Open: return a copy of the internal structure

As we modify the struct fields when closing, we don't want to lose the
internal representation of the file, in case we want to reopen it.

Return a copy of the File, although we keep using the same pointers to
tar.Header and buffer.Reader. Maybe we will need to change that in the
future.

* tarfs: implement Fs.OpenFile

* tarfs: use Fatalf for unexpected error in TestFsOpen

* tarfs: add tests for Fs.Stat

* tarfs: implement Fs.Stat

* tarfs: remove TestNewFs

That test depends too much on the internal imlementation, and it is
easier to break if we change it.

* tarfs: remove unused code

* tarfs: change internal implementation

To be able to handle directories (File.Readdir, File.Readdirnames), the
naive single-map implementation makes it a bit harder to implement.

Inspired by the zipfs backend, switch to an internal implementation of a
map of directories that contains a map of files, so the directory
methods are easier to implement.

Also, treat the "virtual" filesystem as absolute, just like zipfs does.

* tarfs: use Fatal errors to avoid panics

* tarfs: add pseudoroot

* tarfs: add tests for File.Readdir

* tarfs: add pointer Fs in the File structure

For directory-related operations we will need to access the internal
structure in the Fs.

As Readdir and Readdirnames are File methods, we need to access such
structure from the File.

* tarfs: fix error

* tarfs: use just the names for TestReaddir, easier than using fill os.FileInfo entries

* tarfs: create a copy of the original entry when opening a file

We added the fs field in the File struct to reference the underlying Fs
object, but in the Open cal we were not passing it, making all the
opened files to have a nil pointer in that field.

Change to make a copy of the original file, and returning that

* tarfs: implement File.Readdir

* tarfs: add tests for File.Readdirnames

* tarfs: implement Readdirnames

* tarfs: add test for File.Name

* tarfs: change tests to use the Afero interface instead

* tarfs: add tests for Glob from zipfs

* tarfs: update main repo references to tarfs

* tarfs: use OS-specific file separator for pseudoroot

* tarfs: fix path handling in Windows systems
2020-09-14 20:44:56 +02:00
mem mem: fix Write setting wrong offset 2020-09-02 11:39:23 +06:00
sftpfs Merge pull request #158 from kklin/sftp-openfile 2020-04-11 00:22:21 +02:00
tarfs Add tarfs implementation (reopen #265) (#266) 2020-09-14 20:44:56 +02:00
zipfs Fix panic when not filling up zipfs's read buffer 2020-06-25 23:27:17 -05:00
.gitignore Build and test CI improvements 2020-03-28 14:01:49 +01:00
.travis.yml Add tarfs implementation (reopen #265) (#266) 2020-09-14 20:44:56 +02:00
LICENSE.txt afero is born 2014-10-28 10:29:28 -04:00
README.md Add tarfs implementation (reopen #265) (#266) 2020-09-14 20:44:56 +02:00
afero.go Fix typo in RemoveAll code comment 2016-11-09 01:09:53 +01:00
afero_test.go Return error in Readdir on regular mem file 2018-05-31 11:51:01 +02:00
appveyor.yml Build and test CI improvements 2020-03-28 14:01:49 +01:00
basepath.go adding support for Linker and LinkReader 2020-05-20 23:00:47 +10:00
basepath_test.go Gofmt the project 2020-04-10 23:59:22 +02:00
cacheOnReadFs.go Make the merge func in UnionFile configureable 2018-04-01 22:57:52 +02:00
composite_test.go Fix amount of files read in UnionFile.Readdir 2020-08-23 02:36:25 +03:00
const_bsds.go Add AIX support 2019-07-04 15:58:10 +02:00
const_win_unix.go Add AIX support 2019-07-04 15:58:10 +02:00
copyOnWriteFs.go adding support for Linker and LinkReader 2020-05-20 23:00:47 +10:00
copyOnWriteFs_test.go Return nil in CopyOnWriteFs.MkdirAll when directory exists 2018-12-17 09:55:40 +01:00
go.mod Removing use of testify 2020-09-13 14:01:19 -05:00
go.sum go.mod: bump golang.org/x/text to v0.3.3 2020-08-06 16:04:07 +02:00
httpFs.go Migrate all backends & readme to use constructorish New... 2016-01-11 21:41:03 -05:00
ioutil.go Add implementation for TempFile with wild card prefix 2020-01-06 22:31:16 -08:00
ioutil_test.go Add implementation for TempFile with wild card prefix 2020-01-06 22:31:16 -08:00
lstater.go Add an optional Lstater interface 2018-04-01 22:57:51 +02:00
lstater_test.go Add an optional Lstater interface 2018-04-01 22:57:51 +02:00
match.go match: change strings.IndexAny to strings.ContainsAny 2019-01-10 23:22:24 +05:00
match_test.go Gofmt the project 2020-04-10 23:59:22 +02:00
memmap.go Make MemMapFs implement Lstater 2020-09-07 00:05:27 -05:00
memmap_test.go Removing use of testify 2020-09-13 14:01:19 -05:00
os.go adding support for Linker and LinkReader 2020-05-20 23:00:47 +10:00
path.go Add an optional Lstater interface 2018-04-01 22:57:51 +02:00
path_test.go Fix closing and deleting of files in tests 2015-12-09 23:35:59 -06:00
readonlyfs.go adding support for Linker and LinkReader 2020-05-20 23:00:47 +10:00
regexpfs.go Add missing error check in RegexpFs Open 2020-04-18 19:14:24 +02:00
ro_regexp_test.go Migrate all backends & readme to use constructorish New... 2016-01-11 21:41:03 -05:00
symlink.go adding support for Linker and LinkReader 2020-05-20 23:00:47 +10:00
symlink_test.go adding tests for Linker and ReadLinker interfaces 2020-05-20 23:00:48 +10:00
unionFile.go Fix amount of files read in UnionFile.Readdir 2020-08-23 02:36:25 +03:00
util.go Return error instead of panic in WriteReader 2018-01-15 20:27:20 +01:00
util_test.go Gofmt the project 2020-04-10 23:59:22 +02:00

README.md

afero logo-sm

A FileSystem Abstraction System for Go

Build Status Build status GoDoc Join the chat at https://gitter.im/spf13/afero

Overview

Afero is a filesystem framework providing a simple, uniform and universal API interacting with any filesystem, as an abstraction layer providing interfaces, types and methods. Afero has an exceptionally clean interface and simple design without needless constructors or initialization methods.

Afero is also a library providing a base set of interoperable backend filesystems that make it easy to work with afero while retaining all the power and benefit of the os and ioutil packages.

Afero provides significant improvements over using the os package alone, most notably the ability to create mock and testing filesystems without relying on the disk.

It is suitable for use in any situation where you would consider using the OS package as it provides an additional abstraction that makes it easy to use a memory backed file system during testing. It also adds support for the http filesystem for full interoperability.

Afero Features

  • A single consistent API for accessing a variety of filesystems
  • Interoperation between a variety of file system types
  • A set of interfaces to encourage and enforce interoperability between backends
  • An atomic cross platform memory backed file system
  • Support for compositional (union) file systems by combining multiple file systems acting as one
  • Specialized backends which modify existing filesystems (Read Only, Regexp filtered)
  • A set of utility functions ported from io, ioutil & hugo to be afero aware

Using Afero

Afero is easy to use and easier to adopt.

A few different ways you could use Afero:

  • Use the interfaces alone to define your own file system.
  • Wrapper for the OS packages.
  • Define different filesystems for different parts of your application.
  • Use Afero for mock filesystems while testing

Step 1: Install Afero

First use go get to install the latest version of the library.

$ go get github.com/spf13/afero

Next include Afero in your application.

import "github.com/spf13/afero"

Step 2: Declare a backend

First define a package variable and set it to a pointer to a filesystem.

var AppFs = afero.NewMemMapFs()

or

var AppFs = afero.NewOsFs()

It is important to note that if you repeat the composite literal you will be using a completely new and isolated filesystem. In the case of OsFs it will still use the same underlying filesystem but will reduce the ability to drop in other filesystems as desired.

Step 3: Use it like you would the OS package

Throughout your application use any function and method like you normally would.

So if my application before had:

os.Open('/tmp/foo')

We would replace it with:

AppFs.Open('/tmp/foo')

AppFs being the variable we defined above.

List of all available functions

File System Methods Available:

Chmod(name string, mode os.FileMode) : error
Chtimes(name string, atime time.Time, mtime time.Time) : error
Create(name string) : File, error
Mkdir(name string, perm os.FileMode) : error
MkdirAll(path string, perm os.FileMode) : error
Name() : string
Open(name string) : File, error
OpenFile(name string, flag int, perm os.FileMode) : File, error
Remove(name string) : error
RemoveAll(path string) : error
Rename(oldname, newname string) : error
Stat(name string) : os.FileInfo, error

File Interfaces and Methods Available:

io.Closer
io.Reader
io.ReaderAt
io.Seeker
io.Writer
io.WriterAt

Name() : string
Readdir(count int) : []os.FileInfo, error
Readdirnames(n int) : []string, error
Stat() : os.FileInfo, error
Sync() : error
Truncate(size int64) : error
WriteString(s string) : ret int, err error

In some applications it may make sense to define a new package that simply exports the file system variable for easy access from anywhere.

Using Afero's utility functions

Afero provides a set of functions to make it easier to use the underlying file systems. These functions have been primarily ported from io & ioutil with some developed for Hugo.

The afero utilities support all afero compatible backends.

The list of utilities includes:

DirExists(path string) (bool, error)
Exists(path string) (bool, error)
FileContainsBytes(filename string, subslice []byte) (bool, error)
GetTempDir(subPath string) string
IsDir(path string) (bool, error)
IsEmpty(path string) (bool, error)
ReadDir(dirname string) ([]os.FileInfo, error)
ReadFile(filename string) ([]byte, error)
SafeWriteReader(path string, r io.Reader) (err error)
TempDir(dir, prefix string) (name string, err error)
TempFile(dir, prefix string) (f File, err error)
Walk(root string, walkFn filepath.WalkFunc) error
WriteFile(filename string, data []byte, perm os.FileMode) error
WriteReader(path string, r io.Reader) (err error)

For a complete list see Afero's GoDoc

They are available under two different approaches to use. You can either call them directly where the first parameter of each function will be the file system, or you can declare a new Afero, a custom type used to bind these functions as methods to a given filesystem.

Calling utilities directly

fs := new(afero.MemMapFs)
f, err := afero.TempFile(fs,"", "ioutil-test")

Calling via Afero

fs := afero.NewMemMapFs()
afs := &afero.Afero{Fs: fs}
f, err := afs.TempFile("", "ioutil-test")

Using Afero for Testing

There is a large benefit to using a mock filesystem for testing. It has a completely blank state every time it is initialized and can be easily reproducible regardless of OS. You could create files to your hearts content and the file access would be fast while also saving you from all the annoying issues with deleting temporary files, Windows file locking, etc. The MemMapFs backend is perfect for testing.

  • Much faster than performing I/O operations on disk
  • Avoid security issues and permissions
  • Far more control. 'rm -rf /' with confidence
  • Test setup is far more easier to do
  • No test cleanup needed

One way to accomplish this is to define a variable as mentioned above. In your application this will be set to afero.NewOsFs() during testing you can set it to afero.NewMemMapFs().

It wouldn't be uncommon to have each test initialize a blank slate memory backend. To do this I would define my appFS = afero.NewOsFs() somewhere appropriate in my application code. This approach ensures that Tests are order independent, with no test relying on the state left by an earlier test.

Then in my tests I would initialize a new MemMapFs for each test:

func TestExist(t *testing.T) {
	appFS := afero.NewMemMapFs()
	// create test files and directories
	appFS.MkdirAll("src/a", 0755)
	afero.WriteFile(appFS, "src/a/b", []byte("file b"), 0644)
	afero.WriteFile(appFS, "src/c", []byte("file c"), 0644)
	name := "src/c"
	_, err := appFS.Stat(name)
	if os.IsNotExist(err) {
		t.Errorf("file \"%s\" does not exist.\n", name)
	}
}

Available Backends

Operating System Native

OsFs

The first is simply a wrapper around the native OS calls. This makes it very easy to use as all of the calls are the same as the existing OS calls. It also makes it trivial to have your code use the OS during operation and a mock filesystem during testing or as needed.

appfs := afero.NewOsFs()
appfs.MkdirAll("src/a", 0755)

Memory Backed Storage

MemMapFs

Afero also provides a fully atomic memory backed filesystem perfect for use in mocking and to speed up unnecessary disk io when persistence isnt necessary. It is fully concurrent and will work within go routines safely.

mm := afero.NewMemMapFs()
mm.MkdirAll("src/a", 0755)

InMemoryFile

As part of MemMapFs, Afero also provides an atomic, fully concurrent memory backed file implementation. This can be used in other memory backed file systems with ease. Plans are to add a radix tree memory stored file system using InMemoryFile.

Network Interfaces

SftpFs

Afero has experimental support for secure file transfer protocol (sftp). Which can be used to perform file operations over a encrypted channel.

Filtering Backends

BasePathFs

The BasePathFs restricts all operations to a given path within an Fs. The given file name to the operations on this Fs will be prepended with the base path before calling the source Fs.

bp := afero.NewBasePathFs(afero.NewOsFs(), "/base/path")

ReadOnlyFs

A thin wrapper around the source Fs providing a read only view.

fs := afero.NewReadOnlyFs(afero.NewOsFs())
_, err := fs.Create("/file.txt")
// err = syscall.EPERM

RegexpFs

A filtered view on file names, any file NOT matching the passed regexp will be treated as non-existing. Files not matching the regexp provided will not be created. Directories are not filtered.

fs := afero.NewRegexpFs(afero.NewMemMapFs(), regexp.MustCompile(`\.txt$`))
_, err := fs.Create("/file.html")
// err = syscall.ENOENT

HttpFs

Afero provides an http compatible backend which can wrap any of the existing backends.

The Http package requires a slightly specific version of Open which returns an http.File type.

Afero provides an httpFs file system which satisfies this requirement. Any Afero FileSystem can be used as an httpFs.

httpFs := afero.NewHttpFs(<ExistingFS>)
fileserver := http.FileServer(httpFs.Dir(<PATH>))
http.Handle("/", fileserver)

Composite Backends

Afero provides the ability have two filesystems (or more) act as a single file system.

CacheOnReadFs

The CacheOnReadFs will lazily make copies of any accessed files from the base layer into the overlay. Subsequent reads will be pulled from the overlay directly permitting the request is within the cache duration of when it was created in the overlay.

If the base filesystem is writeable, any changes to files will be done first to the base, then to the overlay layer. Write calls to open file handles like Write() or Truncate() to the overlay first.

To writing files to the overlay only, you can use the overlay Fs directly (not via the union Fs).

Cache files in the layer for the given time.Duration, a cache duration of 0 means "forever" meaning the file will not be re-requested from the base ever.

A read-only base will make the overlay also read-only but still copy files from the base to the overlay when they're not present (or outdated) in the caching layer.

base := afero.NewOsFs()
layer := afero.NewMemMapFs()
ufs := afero.NewCacheOnReadFs(base, layer, 100 * time.Second)

CopyOnWriteFs()

The CopyOnWriteFs is a read only base file system with a potentially writeable layer on top.

Read operations will first look in the overlay and if not found there, will serve the file from the base.

Changes to the file system will only be made in the overlay.

Any attempt to modify a file found only in the base will copy the file to the overlay layer before modification (including opening a file with a writable handle).

Removing and Renaming files present only in the base layer is not currently permitted. If a file is present in the base layer and the overlay, only the overlay will be removed/renamed.

	base := afero.NewOsFs()
	roBase := afero.NewReadOnlyFs(base)
	ufs := afero.NewCopyOnWriteFs(roBase, afero.NewMemMapFs())

	fh, _ = ufs.Create("/home/test/file2.txt")
	fh.WriteString("This is a test")
	fh.Close()

In this example all write operations will only occur in memory (MemMapFs) leaving the base filesystem (OsFs) untouched.

Desired/possible backends

The following is a short list of possible backends we hope someone will implement:

  • SSH
  • S3

About the project

What's in the name

Afero comes from the latin roots Ad-Facere.

"Ad" is a prefix meaning "to".

"Facere" is a form of the root "faciō" making "make or do".

The literal meaning of afero is "to make" or "to do" which seems very fitting for a library that allows one to make files and directories and do things with them.

The English word that shares the same roots as Afero is "affair". Affair shares the same concept but as a noun it means "something that is made or done" or "an object of a particular type".

It's also nice that unlike some of my other libraries (hugo, cobra, viper) it Googles very well.

Release Notes

See the Releases Page.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Contributors

Names in no particular order:

License

Afero is released under the Apache 2.0 license. See LICENSE.txt