issue:
1. create a 2MB file: dd if=/dev/zero of=testfile bs=1024 count=2048
2. size chunk to 1MB
what we see: progress up to 50%, then stop and jump to 100%
before this, if the user had a full disk, there wouldn't be any error
reported back whenever editing something in the admin
console as file.Close() would return nil ....
The only way to go around it is to wait for the sync to be done.
I've seen the case where someone ran out of disk with a corrupted config
file which gave the following fatal error in the login screen:
Uncaught TypeError: Cannot read properties of null (reading 'map')
with a stacktrace pointing to: ctrl_form.js:22:63
this fixes the assumptions on the config file so as to not trigger the
fatal error but head to the nicer error cases where it would say:
Internal Error: There is nothing here.
which is much nicer for end users than "Cannot read properties of null"
Cloudflare does limit the size of file upload by an arbitrary number. We
can go around that by using chunked upload but somehow that wasn't
enough, to circumvent that issue, we make it clear to the proxy it
should close the connection and we hope the problem we go away
on a mobile like screen, the sidebar wouldn't be hidden entirely, it
would still show the border artifact. We need to make sure the default
is to be of class hidden to prevent such artefact
whenever reading an audio file, quitting and coming back, the audio
context under wavesurfer.backend.ac would show a currentTime that is not
actually reset properly. Closing or trying several trick didn't fix the
issue, hence this approach which is quite dirty but work.
Overall wavesurfer has some weird tendencies, this is just one more hack
within the audio player
When we have a single storage selected, we automatically redirect the
user to it as we don't need to wait for a user action. The thing is we
used to have this UI being shown with a button that didn't make sense.
Instead we want to show the loader when we reach those condition
when toggling off the settings for a shared links, the value wouldn't
be actually turned off. We're now ensuring that anything with an "enabled"
checkbox is turned on/off on demand
