Skip to content

Releases: spf13/afero

v1.9.1

19 Jul 09:13
@bep bep

Choose a tag to compare

What's Changed

  • Fix sorting in IOFS.ReadDir by @bep in #372

Full Changelog: v1.9.0...v1.9.1

v1.9.0

14 Jul 18:02
@bep bep
b0a534a

Choose a tag to compare

What's Changed

  • Update go.mod to reflect that afero requires go >= 1.15.10 by @jeffwidman in #346
  • Move CI tests to GitHub Action by @bep in #367
  • Misc build/test fixes by @bep in #368
  • Fix staticcheck lint errors by @bep in #369
  • Make IOFS.ReadDir check for fs.ReadDirFile by @bep in #366

New Contributors

Full Changelog: v1.8.2...v1.9.0

v1.8.2: RemoveAll fixes in MemMapFs and GcsFs

11 Mar 10:24

Choose a tag to compare

v1.8.1: memfs: add modTime on folder creation

05 Feb 10:30
450b30f

Choose a tag to compare

Merge pull request #334 from KastenMike/add-modTime-to-folders

add modTime on folder creation

v1.8.0: Support sftpfs.Readdirnames, sftpfs.Readdir, CacheOnReadFs bugfix

05 Jan 09:20
cd35605

Choose a tag to compare

  • sftpfs: Add support for Readdirnames and Readdir
  • CacheOnReadFs: Call OpenFile instead of Open in CacheOnReadFs.OpenFile

v1.7.1: Move GCS into its own package

28 Dec 23:00
d8a4ef9

Choose a tag to compare

Merge pull request #333 from drakkan/gcsfs

GCS fs: move all gcsfs related implementations to its own package

v1.7.0: Add experimental GCS support

22 Dec 10:18
d70f944

Choose a tag to compare

Add experimental GCS support in Afero. Experimental because the CI infra of afero does not test with real GCS buckets.

Limitations:

  • No Chmod support - The GCS ACL could probably be mapped to *nix style permissions but that would add another level of complexity and is ignored in this version.
  • No Chtimes support - Could be simulated with attributes (gcs a/m-times are set implicitly) but that's is left for another version.
  • NOTE: Not thread safe - Also assumes all file operations are done through the same instance of the GcsFs. File operations between different GcsFs instances are not guaranteed to be consistent.

Performance implications

  • Sequential reads are performant
  • Sequential writes are performant.
  • Seek + Read or ReadAt is performant after the initial seek. (produces a warning)
  • Alternating reads/writes to the same file handler are highly inefficient. To get consistent FS behavior using an API that separates readers and writers we close any open readers before an write as well close open writers before a read (ensure the data is committed).
  • Seek + Write such as WriteAt, Truncate, Seek+Write will work as expected but with significant overhead. Doing a seek + write will in effect download the old file/object, overlay it with the new writes and save it back. This is done in a streaming fashion so large files will not clog the memory but will trigger a full download and upload of the file/object.

v1.6.0: go1.16 io/fs.FS support

20 Mar 14:24
bc94f58

Choose a tag to compare

  • Add support for go1.16 io/fs.FS interface
  • Fix incorrect WriteAt implementation for mem.File

v1.5.1: Fix setting gid in chown implementation

09 Dec 12:18
32b5faa

Choose a tag to compare

Merge pull request #280 from mfuterko/master

Fix a typo

v1.5.0: Add chown support

07 Dec 19:55
816954d

Choose a tag to compare

Remove go1.13 from travis build matrix