5ht2 / fs-over-http Goto Github PK

I don't think an fmt.Fprintf for each individual file is the best idea for large directories, given my screenshots folder is reaching ~5000 screenshots.

Below is the current code for printing it:

https://github.com/l1ving/fs-over-http/blob/bdd0e31a7cea69d470fe23a07aa04b991acd303c/main.go#L255-L282

Sending it as one request or a stream would be ideal.

I'm having way too many issues with redis persistence, and honestly, a beats key in a redisjson database with 265020 values (it is literally a json array with 265,020 values in the root key) is not the best way to go about this.

This is exactly the sort of thing SQL is for and I wish I knew that when I decided to write this project 2 years ago, so it's time to fix it (after Christmas, ideally).

I just noticed this and tbqh, I have no idea why it happens. Will fix later, it's not too big of an issue.

Can I get some advice?

Send a request to a location that doesn't exist (eg https://i.l1v.in/asdf/)

Expected response

Some variation of 404 Not Found with a status of 404

Actual response

500 stat filesystem/public/asdf: no such file or directory with a status of 500

https://github.com/l1ving/fs-over-http/blob/5865251d5297ea7d2a5fca6d81b5e66bdd076004/main.go#L327 this looks like it's to blame?

Github has support for storing your Docker images on Github, instead of Docker Hub. The GH Action that we're using currently does not need you to change much to add support for this.

The reasoning behind this is that Docker now only allows 1 personal access token for pushing your containers, and org plans are paid. Given this push to pay for Docker Hub (which enforces poor security practices), it would be better to switch to GH for hosting the images.

• Switch Action and Makefile
• Update update.sh script

It seems that anything above ~1GB gets foh killed very quickly. I think this has something to do with either how the file is being read or how fasthttp works

A possible workaround is using a byte stream instead

I just realized the minimum latency for serving one JSON file is ~30ms on localhost and it should not be this big.

The disk read for the file barely takes a millisecond, it's all in our handling logic and negotiating a localhost connection.