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

Add a fs that reads converts achiveFS to a seekable version #342

Open
WeidiDeng opened this issue Aug 15, 2022 · 2 comments
Open

Add a fs that reads converts achiveFS to a seekable version #342

WeidiDeng opened this issue Aug 15, 2022 · 2 comments

Comments

@WeidiDeng
Copy link
Contributor

What would you like to have changed?

A similar implementation like tarfs or zipfs is appreciated.

Why is this feature a useful, necessary, and/or important addition to this project?

For performance and intuitivity. Current implementation of archiveFs is a glorified extract operation that tries to extract the file from the reader. Also due to the different arcive layout, some file may be at end the of archive. Every time a file is requested the process repeats which is bad for performance.

an FS.fs can be used in http.Filesystem, however because of archiveFs is implemented, file object can't be seeked, which means when golang http can't figure out content-type from file name or client requested range seek will fail, leading to error.

What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?

In cloudreve, registering a mime type is all that's needed.

Please link to any relevant issues, pull requests, or other discussions.

Performance issues, seek error, cloudreve ttf can't be recognized without seeking on windows.

There is a hack for tar, but I doubt you are willing to do this for tar, rar or zip etc.

@mholt
Copy link
Owner

mholt commented Aug 16, 2022

Sounds great, I just have no idea how that works. You have to iterate the archive to get its file listing and get to the file, right?

@WeidiDeng
Copy link
Contributor Author

I implemented a version that is heavily influenced by afero.ZIpfs and it's working great at the moment.

By the way, I found out that when serve http with plain archiveFS and some tar files I created from random git repo, only the root directory can be opened, subdirectory either return 404 or open a file with that prefix in the archive. I suspect when traversing the archive file, there are more corner cases and http interaction to be tested.

Will open a pr later when I tested more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants