hack-pad / hackpadfs Goto Github PK

// Sub implements hackpadfs.SubFS
func (fs *FS) Sub(dir string) (hackpadfs.FS, error) {
	if !hackpadfs.ValidPath(dir) {
		return nil, &hackpadfs.PathError{Op: "sub", Path: dir, Err: hackpadfs.ErrInvalid}
	}
	return &FS{
		root: path.Join(fs.root, dir),
	}, nil
}

I'd like to use Sub but get back the original *FS. So I think this would have to be a stand alone method, similar to context.WithCancel.

It’s on all browsers finally

https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

some simple examples:

https://github.com/WICG/file-system-access/blob/main/EXPLAINER.md

it would be really cool and is designed for browser based editors.

also indexdb has sone gremlins that this API removes. I guess indexdb could be you in browser cache of what’s in the users OS file system though.

there is possibly a lot we can leverage already in this code base already too

I'm curious what this brings to the table that https://github.com/spf13/afero does not have?

Given the conditions:

1. Current working directory is not /. (Say /tmp for example.)
2. Get fs with: fsys, _ := hackpadfs_os.NewFS().Sub("mydir") (Assume /tmp/mydir/ exists.)
3. Call fsys.Stat(".")

Stat fails with:

stat : no such file or directory

While debugging this, it is apparent that this is caused by fs.rootedPath assuming that the sub path is an absolute path, not a path relative to the cwd. I.e. given the example situation, it runs os.Stat("/mydir"), not os.Stat("/tmp/mydir") which is what I would expect.

The following go playground demonstrates: https://go.dev/play/p/hYuq0VNVybc

It seems Sub is not safe to use with paths relative to the cwd, and given that you can't use rooted paths (gofs.ValidPath disallows them), it is not usable in general.

hey @JohnStarich

I was exploring how i can have a file cache.

the idea if that the clients ( web or native) can make requests to S3, but the results are cached, such that future requests use the cache, or on a cache miss use S3. This make writing code on top of hackpadFS much easier if your using it with s3.

https://github.com/NinesStack/filecache seems like a good fit for this.

If you have any thoughts on this before i start on this please feel free to let me know what you think...

Hey there. Really cool project! Just trying this out and using a mem.NewFS() in a test works great. When I swap out my implementation with a os.NewFS(), I'm getting the following error.

mkdir out: read-only file system

My understanding was that os was writable. Is that incorrect?

For context, I'm writing a scaffolding tool that creates a bunch of directories and files. I'm looking for a library that can encapsulate the directory structure I'm creating and ease testing.

Hey team - few unresponded to issues, is this still maintained?

Hey team, really been enjoying the library so far.

If we could add compatibility with https://pkg.go.dev/testing/fstest#TestFS that would speed up testing.

Sorry. Maybe the question is somewhat stupid.
I want to know how to build HackpadFS on my cloud server, through which I can store different types of data on the file system.
What I want is a storage system, which is between SQL and NoSQL. SQL system cannot storage many types of data. NoSQL is too flexible.
I hope the HackpadFS is the solution.
The point is how to build HacpadFS

Wondering if this is designed to provide an unified API for both Browser and Native ( mobile and desktop).

I am attempting to use this with gioui.org.
https://github.com/gioui

I got some basic code working for Browser, but struggled to get it also working for Native.

When calling hackpadfs.Sub, any of the hackpadfs extensions become unavailable on the sub FS. (unless the FS implements SubFS) This is because it calls out to fs.Sub, which wraps it in a type that "covers" up the hackpadfs extension methods.

Minimal Reproduction

https://go.dev/play/p/89L4QJs-Qf3

I need the ability to mock out os.Getwd. probably also Chdir.

Would you be open to accepting a PR adding context aware operations to hackpadfs, which fall back to non-context operations if the implementation doesn't support it?

This is largely for scenarios where the implementation is a cloud storage provider.

I think it would be cool if the https://pkg.go.dev/embed package was supported.

Tinygo just got support for EMbed as well as generics https://github.com/tinygo-org/tinygo/releases/tag/v0.24.0

Dependency line:

github.com/hack-pad/hackpadfs/examples --> github.com/minio/minio --> github.com/gomodule/redigo

github.com/minio/minio 9ca25bd --> github.com/gomodule/redigo v1.8.5

https://github.com/minio/minio/blob/9ca25bd48f7fec228f246ef5452465be009d4d7a/go.mod#L234

Background

Repo github.com/minio/minio at version 9ca25bd uses replace directive to pin dependency github.com/gomodule/redigo to version v1.8.5.

According to Go Modules wikis, replace directives in modules other than the main module are ignored when building the main module.
It means such replace usage in dependency's go.mod cannot be inherited when building main module. And it turns out that github.com/hack-pad/hackpadfs/examples indirectly relies on gomodule/[email protected], which is different from the pinned version minio/minio needed.

https://github.com/hack-pad/hackpadfs/blob/main/examples/go.mod(Line 76)

github.com/gomodule/redigo v2.0.0+incompatible // indirect

https://github.com/minio/minio/blob/9ca25bd48f7fec228f246ef5452465be009d4d7a/go.mod(line 32&234)

github.com/gomodule/redigo v2.0.0+incompatible
replace github.com/gomodule/redigo => github.com/gomodule/redigo v1.8.5

So this is just a reminder in the hope that you can notice such an inconsistency.

Solution

1. Bump the version of dependency github.com/minio/minio

You may try upgrading dependency github.com/minio/minio to a newer version, which may have eliminated the use of this directive.

2. Add the same replace rule to your go.mod

replace github.com/gomodule/redigo => github.com/gomodule/redigo v1.8.5