Add a fs that reads converts achiveFS to a seekable version

[WeidiDeng]

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]

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]

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.