Thursday, 20 March 2025
Stuff learned on this day!
So today/the time between the previous post and now, I have thrown away the idea of doing a login system. I came to this
when, after a while trying to figure out how to do it in Blazor, realized that only I would be logging in and no one
else.
Therefor, it made no sense to have a login system that was only for me. So I went back to the drawing board and
realized,
I can easily upload the files through SMB to my NAS. I simply created a new Dataset and bind the Docker container that
my site uses, to that Dataset. So my Docker container sees wwwroot/external/blogs
in its container. There is an
interesting effect though. I have no idea why but, for some reason when my site goes to read the file names, it crashes
when that binding is set to read-only.
Figuring out what is going on.
I still have no idea what is going on, maybe one day I will though. In any sense, I started by doing the forbidden, the
horrible, the thing all IT Security personal knows is bad, I did the unholy, 777
permissions. That didn't fix the
issue though, relieved knowing that permissions wasn't the issue, I decided to set the binding to rw
, and now my site
doesn't crash when reading the file names. I still don't have the answer, and I would love to make that bind ro
to
help prevent any case of abuse.
My current theory is that .NET is doing something under the hood, where it is requesting write permissions to the
folder.
It shouldn't, but this is Microsoft of course, it is the same people who can't make a stable OS from my experience. The
same people who released a bug that deleted files for people with certain CPUs. I digress though, for as if this is
correct, it makes no sense why .NET would want to have write access to a folder that is it reading from.
ES MACHT KEINEN SINN! My other theory is that, somewhere in my code, or in the .NET APIs, it opens a file then
closes the fd
when reading file names. If this is the case, I would consider it a bug.
Update to Site
By the way, as stated above, I did update the site to be a lot more responsive. Instead of having a database that stores
all the blog file locations, names, and date. The site will actually use the file name as the date, and it knows that
all blogs are located in /wwwroot/external/blogs
. This means that any time, say, the site is reloaded or the page
updates in any way, the server will look through that directory for any new blog files. It will also check for deleted
ones as well. I think, however, in the future I might update it to cache all the blog locations and date. With how it is
currently is:
- Pro
- Updates in real time.
- No bloated middleman.
- No database to manage.
- Con
- The server has to spend time re-looking at files that probably won't change for months.
- This wastes cycles on a useless task.
- Slows down loading time the more blogs there are.
- I am relying on the file system response.
- The server has to spend time re-looking at files that probably won't change for months.
What I have been thinking is keeping a memory map or creating a cache file. The benefits of a cache file is that all
of that info is stored in 1 place, and one idea is re-introducing the SQLite DB for that job, as the cache file would
be just storing the date and the path of the file. Another option is using a simple dictionary like
Dictionary<DateOnly,string>
to store both the date and the path. And another option would creating a new class to
store the info. The thing I can think of off the top of my head is:
public sealed class Blog { public DateOnly Date { get; private set; } public string Path { get; private set; } public Blog(DateOnly date, string path){ Date = date; Path = path; } }
Of course this is a rough draft of the class, but that might be interesting to do. The downside to this is that it
may consume a lot of memory when it comes to having a lot of blogs. One quick way to remedy this would be to only
store the Date
, as that is only 3 int
's. So it would look something like:
public sealed class Blog { public DateOnly Date { get; private set; } public string Path => $"wwwroot/external/blogs/{Date.Day}-{Date.Month}-{Date.Year}.md"; public Blog(DateOnly date){ Date = date; } }
This would enable the class to be smaller and allow for more in memory, but then the issue comes from it just sitting in memory doing nothing. Would it be fast? Yes, but at the cost of hogging memory. I think the best route would be to use the SQLite DB as a cache file. This is what databases are designed for, and namely SQLite.
If you couldn't tell, I hate unoptimized code. Stop throwing hardware at a software issue companies!