| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Now I will know if something breaks horribly again.
|
| |
|
|
|
|
| |
Iterator::skip_while() returns the last item. Reimplement the
combinator that I need using a loop over Iterator::by_ref()
instead. This will terminate after the end is reached.
|
| | |
|
| |
|
|
| |
Closes #4.
|
| |
|
|
|
|
|
|
|
| |
Templates and utility types are now separate crates to speed up
compilation, linting and potential reuse/replacement.
Potentially more crates could be split out/modularized, resulting in
speedups, smaller binaries (whenever features are excluded) and even
more reuse capabilities.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Reads don't lock anymore. At all.
- Writes create a temporary file and use `rename(2)` to atomically
replace it
- since OpenOptions::create_new(true) is used, tempfile creation is
atomic (and since tempfile names are per-post, a post can only be
edited by one request at a time)
- Since written files get atomically replaced, readers can't read a
corrupted file
Potential pitfalls:
1. This approach is not covered by unit tests (yet)
2. Stale tempfiles can prevent editing posts (can be solved by
throwing out tempfiles that are older than, say, a day)
3. Crashed edits can leave stale tempfiles (honestly that sounds
better than corrupting the whole database, doesn't sound like a bug to
me at all!)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Warp allows requests to be applied as "filters", allowing to flexibly
split up logic and have it work in a functional style, similar to
pipes.
Tokio is just an alternative runtime. I thought that maybe switching
runtimes and refactoring the code might allow me to fish out that
pesky bug with the whole application hanging after a certain amount of
requests...
|
| |
|
|
|
|
| |
This is to prevent spinning in a loop waiting for a lock. This hangs
often, though I suspect this should have been fixed in the previous
commit.
|
| |
|
|
|
|
|
| |
This may or may not be the cause for the app hanging while waiting for
a lock. Now the operations with locks are never performed over an
async boundary, excluding any shenanigans that can happen when
accidentally leaving a file locked over async boundaries.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will allow readers to view private posts intended just for them.
Additionally fixed bugs in patterns due to which webmentions might not
have been sent.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Thanks to @Kloenk I was able to get rid of the unsafety and
tell the compiler how to properly check what I needed for
the StorageError to be declared thread-safe.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
When an error is found, the site name passed to Storage::get_setting
in the error handler is incorrect. The ASCII serialisation of the
hostname should get used.
|
| | |
|
| | |
|
| |
|
|
|
| |
BufReader was really unneccesary here, since I was batch-reading all
of this in one go.
|
| |
|
|
|
|
| |
Now symlink creation works on Windows and creates links relative to
the posts, allowing for seamless migrations of the backing directory
for true portability and no data lock-in.
|
| | |
|
| |
|
|
|
|
| |
Now the Redis dependencies are optional and only required if you want
to test the backend or actually use it in production. The app displays
a hint if you try to launch with an unsupported backend.
|
| |
|
|
|
|
|
|
|
|
|
| |
There was a bug where `File::write()` would not write the entire
buffer, and this condition was left unchecked by the code. All
`File::write()` calls are now replaced with `File::write_all()` which
ensures the whole buffer is written to the backing file.
Additionally added a smoke check for the file updates. It is in no way
comprehensive nor it is able to catch all the possible failures but
it's a good way of testing the functionality without way too much hassle.
|
| |
|
|
|
|
|
| |
Currently unavailable for use and only has basic GET and POST operations
implemented. A lot more work is needed to make it truly usable.
Locking is implemented using flock() system call on Linux.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
for future reference: stream operations returning Result satisfy
conditions for the futures::stream::TryStreamExt trait, allowing you to
use `TryStreamExt::try_collect::<T>()` and receive a Result<T>.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
